---

How Xocolatl  made its way into the Old World, Russia, etc.?

Strategically, logistically, and militarily buttressed by thousands of indigenous mortal enemies of the Aztec / Mexicah, the Spanish scum enslaved, raped, looted... destroyed, the 'New World' --subsequently attacking even dissenting 'allies'. Only midway thru, i.e., some 40 million deaths, their barbaric genocide -- which has not ended yet -- they quickly acquired a taste for xocolatl -- which they had initially scorned -- and corrupted the word into their Spanish dialect as 'chocolate' and thus began exporting its plunder towards Europe.
...
Pardon my Deviation or memory focus lapse. Now we begin -- 'for reals' Campa Tzintica [Where it Begins]:

---

A couple of days before nginx announced it was being acquired by F5 Networks, I came across a Metztli Reiser4 deployment of new Modsecurity v3.0.3 standalone module and Engine X, i.e., nginx which, unbeknownst to me -- more familiar with Apache HTTPD builds -- required an 'nginx connector'. I tried to install packages from the Linux OS metaframework, i.e., Debian, --which Stretch AMD64 flavour underlies Metztli Reiser4-- to no avail as those packages will be available in next Debian Buster distribution. And even then, as of yet, the modsecurity nginx connector does not appear to be included in the Buster nginx packages.

After some research online and preliminary trial and error builds, it became evident that I had to build libmodsecurity3 module, and install it, before I could build its nginx connector. Moreover, I could not build the libmodsecurity3 module outside of the 'Debian way' paradigm if I intended to build its nginx connector properly within --as it complained of unknown dependencies. To summarize, for simplicity and reuse across Metztli Reiser4 deployments I had to build both libmodsecurity3 module and its nginx connector within the 'Debian way' paradigm by implementing a(nother) hack arrived at by inductive reasoning and not guided by Debian policy. Accordingly, the following hack, too, is driven by pragmatism and the inherent meritocracy enabled by free and open source software (FOSS) rather than by adherence to the pedantry of Debian developers' alleged 'philosophy'.

From Debian relevant packaging for Buster build ModSecurity v3 stand-alone module for stretch-backports.

Prior to our build we install some dependencies. My development environment is from a Metztli Reiser4 on AMD64 installation hence, by default, I have Debian stretch-backports repository enabled in /etc/apt/sources.list. Accordingly...

Shell

Important note: if libluajit-5.1-dev is present, make sure to purge it as it conflicts with liblua5.3-dev leading to failed ModSecurity v3 build.

I proceed to get the latest ModSecurity from git, download the Debian ModSecurity v3 packaging, and properly expand latter into ModSecurity directory by use of -C to change to directory during tar archive expansion:

Shell

Please note files ModSecurity/debian/control and ModSecurity/debian/patches/series as we will modify those since, by empirical evidence, most if not all Debian packaging that I have come across will specify libcurl4-gnutls-dev, instead of libcurl4-openssl-dev. And since we downloaded a more recent version of ModSecurity source a couple of patches in the Debian packaging for Buster are redundant and we will disable them appropriately.

Hence, first we prepare the ModSecurity v3 source:

Shell

Following up on my prior assertion, I will use xvi tiny text editor, and modify debian/control file to replace the string gnutls with openssl.

Shell

We verify the success (or lack thereof) of my edit and proceed to modify debian/patches/series to disable a couple of redundant patches. Remember, our ModSecurity source is more recent than Debian Buster's.

Shell

Please note, in xvi to access lower/upper split window, we use char 'g' by itself --as opposed to Ctrl plus char w w used in vim.

I save modifications to the /debian/patches/series file where, as can be observed in prior screenshot, I have disabled the last two(2) redundant patches, i.e.:
# setenv_term_avoid.patch
# bigendian_fix.patch

I accommodate quilt (or my ignorance ) by creating a link to debian/patches and subsequently apply only remaining patch in the series,

Shell

output should show no errors.

As this is Milestone v3.0.4 phase, (Due by November 08, 2019), during my prior build I specified dch -v 3.0.3-2 but you may use default as:

Shell

Please use as guidelines the maintainers' formatting as your write down your line (or two) of annotations; dch will write those to debian/changelog -- as you save your modifications -- and then dch will exit from the text editor that it opened for you.

Start the build procedure as:

Shell

Notice the -d option within brackets above. It is only meant to be used if dpkg-buildpackage complains about a dependency but you know it has been satisfied.

Additionally the X variable next to -j option is to specify number of cores/threads assigned to the task.

The build procedure will take approximately four(4) to five(5) minutes to complete successfully with 6 threads/cores --as illustrated in the command directive shown in screenshot above.

libmodsecurity3_3.0.3-2_amd64.deb
libmodsecurity3_3.0.3-2_amd64.deb.SHA256SUM
libmodsecurity-dev_3.0.3-2_amd64.deb
libmodsecurity-dev_3.0.3-2_amd64.deb.SHA256SUM

Screenshot illustrates we have just built our fabulous libmodsecurity3 in a 'Debian way' hack Now it is time to install the stand alone module --as it will fulfill a dependency prior to our ModSecurity nginx connector build:

Shell

Build ModSecurity Nginx connector as a module for Engine X v1.15.9 to be loaded by Debian nginx-full  instantiation.

We fetch Debian packaging for nginx from Debian Buster repositories -- which currently lags much behind our Engine X target build.

Shell

And proceed to fulfill some dependencies prior to our nginx v1.15.9 hack in debian packaging for nginx that we downloaded:

Shell

Notice the inclusion this time of libluajit-5.1-dev as specified in Debian packaging for nginx --specifically in debian/control file.
And from nginx> download area we download nginx mainline version 1.15.9 -- which is the most recent Engine X available prior F5's acquisition.

Shell

And verify our tarred source:

Shell

If output is similar to:

gpg: Signature made Tue 26 Feb 2019 07:33:53 AM PST
gpg: using RSA key 520A9993A1C052F8
gpg: Can't check signature: No public key

then we download the RSA key specified above:

Shell

Sample output:

gpg: key 520A9993A1C052F8: 6 signatures not checked due to missing keys
gpg: key 520A9993A1C052F8: public key "Maxim Dounin <mdounin@mdounin.ru>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1

Please note that it has been sometime that the key server pgp.mit.edu has not been available as seen in the subsequent screenshot.

I then try again the verification process:

Shell

gpg: Signature made Tue 26 Feb 2019 07:33:53 AM PST
gpg: using RSA key 520A9993A1C052F8
gpg: Good signature from "Maxim Dounin <mdounin[]mdounin.ru>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B0F4 2533 73F8 F6F5 10D4 2178 520A 9993 A1C0 52F8

Hacking Debian Buster packaging for Upstream Nginx v1.15.9 and to build ModSecurity v3 Connector Module

We create a build directory at our current file system location where I assume we have our download sources.

Shell

We proceed to expand Debian Buster packaging for older nginx into current nginx v1.15.9 directory created above (note the -C change directory option to tar)

Shell

We intend to make a patch so as to avoid the tedious manual process upon subsequent builds.

Shell

Next we change to the modules directory, relative to our current file system location, to clone the ModSecurity connector and rename apropriately:

Shell

Notice how most of the module names are prefixed with http-. That gives us a hint on how to name our modsecurity nginx connector module.

Shell

This last command outputs ModSecurity Nginx connector version: v1.0.0

Let's return one directory back to our previous location:

Shell

Inspect our newly cloned http-modsecurity directory for the existence of hidden directory .git and file(s) .travis.yml and, intending to make a subsequent patch, we delete those -- later we will make a note of our action(s) in the control file in this same directory location:

Shell

Now we are going note down our modifications to the http-modsecurity module by editing file control with xvi and positioning our cursor at the very end of the file, thus:

Shell

We will add the following code:

Module: http-modsecurity
Homepage: https://github.com/SpiderLabs/ModSecurity-nginx
Version: 1.0.0
Files-Excluded: .git .travis.yml

Please make sure to leave an extra blank line at the end. Save your modification to our current debian/modules/control editing and exit xvi.

We change our current file system directory location twice backwards to nginx-1.15.9, we verify by performing an ls (and/or pwd) command at our shell.

From now on all our subsequent commands will be entered relative to our current directory location.

Shell

Shell

xvi will open up single debian/control file for editing in two panes with the cursor in the last pane at the end of debian/control text document. We insert a blank line and then the code block below.

Important: pay particular attention to the lines below text string 'Description: The ModSecurity-nginx connector' as they must have a leading blank character.

Package: libnginx-mod-http-modsecurity
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: The ModSecurity-nginx connector
 is the connection point between nginx and libmodsecurity (ModSecurity v3).
 Said another way, this project provides a communication channel between nginx and libmodsecurity.
 This connector is required to use LibModSecurity with nginx.
 .
 The ModSecurity-nginx connector takes the form of an nginx module.
 The module simply serves as a layer of communication between nginx and ModSecurity.
 .
 Notice that this project depends on libmodsecurity rather than ModSecurity (version 2.9 or less).

Now we use char 'g' by itself to proceed to upper xvi pane, at line 153, and we will insert the line directive below (include , at the end).
libnginx-mod-http-modsecurity (= ${binary:Version}),

We save our modification to debian/control and exit this xvi session.

We continue by editing debian/rules. Again, I open two panes with the same file for illustration purposes. xvi will open on the lower pane at specified line number 103:

Shell

I insert below that line number, the following:
--add-dynamic-module=$(MODULESDIR)/http-modsecurity \

I use g to switch to the upper panel and just below line number 22 I insert directive:
http-modsecurity \

That's it! Save your xvi edits to debian/rules file and exit editor.

Next we will create a couple of ModSecurity v3 Nginx Connector Module resource prerequisites to satisfy our 'Debian way' build and subsequent native load module directive. First...

Shell

and insert the following line of script:
load_module modules/ngx_http_modsecurity_module.so;

Subsequently create and open the next file:

Shell

and in this last file we are creating, I insert the following block of code:

#!/usr/bin/perl -w

use File::Basename;

# Guess module name
$module = basename($0, '.nginx');
$module =~ s/^libnginx-mod-//;

$modulepath = $module;
$modulepath =~ s/-/_/g;

print "mod debian/build-full/objs/ngx_${modulepath}_module.so\n";
print "mod debian/libnginx-mod.conf/mod-${module}.conf\n";

Make sure to make the file executable:

Shell

Try for both of these last files not to leave a blank line at the end. Save your edits to your two(2) new files and exit xvi.

Creating a patch against older Debian Buster packaging to enhance it for Nginx 1.15.9

Shell

debian-buster-packaging-for-nginx-1.15.9_and_modsecurity-connector-module.patch

debian-buster-packaging-for-nginx-1.15.9_and_modsecurity-connector-module.patch.SHA256SUM

We Begin Build of Nginx 1.15.9 With Integrated libModSecurity3 Connector Module 'the Debian Way'.

Shell

Warning: verify permissions of debian/libnginx-mod-http-modsecurity.nginx if you get similar error as below midway through the build procedure (see 51 above).

debian/libnginx-mod-rtmp.postrm.debhelper
echo '# End automatically added section' >> debian/libnginx-mod-rtmp.postrm.debhelper
use -- File::Basename; --

debian/rules:152: recipe for target 'override_dh_install' failed
make[1]: Leaving directory '/usr/src/build-dir/nginx-1.15.9'
debian/rules:143: recipe for target 'binary' failed

After a few minutes (7-8 minutes in this machine), the build comes to an end.

libnginx-mod-http-auth-pam_1.15.9-1_amd64.deb
libnginx-mod-http-auth-pam_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-cache-purge_1.15.9-1_amd64.deb
libnginx-mod-http-cache-purge_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-dav-ext_1.15.9-1_amd64.deb
libnginx-mod-http-dav-ext_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-echo_1.15.9-1_amd64.deb
libnginx-mod-http-echo_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-fancyindex_1.15.9-1_amd64.deb
libnginx-mod-http-fancyindex_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-geoip_1.15.9-1_amd64.deb
libnginx-mod-http-geoip_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-headers-more-filter_1.15.9-1_amd64.deb
libnginx-mod-http-headers-more-filter_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-image-filter_1.15.9-1_amd64.deb
libnginx-mod-http-image-filter_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-lua_1.15.9-1_amd64.deb
libnginx-mod-http-lua_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-modsecurity_1.15.9-1_amd64.deb
libnginx-mod-http-modsecurity_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-ndk_1.15.9-1_amd64.deb
libnginx-mod-http-ndk_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-perl_1.15.9-1_amd64.deb
libnginx-mod-http-perl_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-subs-filter_1.15.9-1_amd64.deb
libnginx-mod-http-subs-filter_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-uploadprogress_1.15.9-1_amd64.deb
libnginx-mod-http-uploadprogress_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-upstream-fair_1.15.9-1_amd64.deb
libnginx-mod-http-upstream-fair_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-http-xslt-filter_1.15.9-1_amd64.deb
libnginx-mod-http-xslt-filter_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-mail_1.15.9-1_amd64.deb
libnginx-mod-mail_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-nchan_1.15.9-1_amd64.deb
libnginx-mod-nchan_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-rtmp_1.15.9-1_amd64.deb
libnginx-mod-rtmp_1.15.9-1_amd64.deb.SHA256SUM
libnginx-mod-stream_1.15.9-1_amd64.deb
libnginx-mod-stream_1.15.9-1_amd64.deb.SHA256SUM
nginx_1.15.9-1_all.deb
nginx_1.15.9-1_all.deb.SHA256SUM
nginx-common_1.15.9-1_all.deb
nginx-common_1.15.9-1_all.deb.SHA256SUM
nginx-doc_1.15.9-1_all.deb
nginx-doc_1.15.9-1_all.deb.SHA256SUM
nginx-extras_1.15.9-1_amd64.deb
nginx-extras_1.15.9-1_amd64.deb.SHA256SUM
nginx-full_1.15.9-1_amd64.deb
nginx-full_1.15.9-1_amd64.deb.SHA256SUM
nginx-light_1.15.9-1_amd64.deb
nginx-light_1.15.9-1_amd64.deb.SHA256SUM

---

Note: some of the snapshots illustrating the procedures are not necessarily from the same build and/or time sequence -- nor are they necessarily from a same hostname. They were selected merely to provide the best illustration of the procedures discussed here.
¹ Виктория Одинцова
Linux Journal: ModSecurity and nginx by Elliot Cooper on September 24, 2018
Resizing tmux panes

DISCLAIMER although due diligence has been applied, this resource is made available for testing/evaluation purposes on an AS IS basis. The procedure only reflects my own modifications, my limited testing, and the potential user(s) who execute(s) the procedures assumes all risks.

Please do not hold me or Metztli Information Technology (and/or its associates) responsible if the information provided here does not achieve the desired result. The information is provided AS IS and with the hope that it may be useful to the Internet community --especially those interested in Engine X (Nginx) on Metztli Reiser4 / Debian for stretch-backports AMD64.

Notwithstanding, There is no implicit or explicit guarantee that the information presented here is accurate --even though due diligence was exercised during the procedure. Accordingly, if an user(s) decide to use the resources available here and/or implement the procedure and/or shell commands described here she, he, or them, do so at her, his, or their own risk. You have been forewarned.

Metztli IT, but not other entities, reserves the right to modify the content and/or even delete it, including blog post, without previous notice.