Installing Third-Party Modules#
In addition to our own dynamic modules for
Angie and Angie PRO,
we collect and publish packages for a number of popular nginx-compatible third-party modules,
developed outside our company, in our repository. Third-party module packages are installed from our repository just like our own packages: To use the installed module in configuration,
load it using the load_module directive in the Tip Package names and the modules themselves in the configuration have the following prefixes: Angie: Angie PRO: Note We do not review the source code of these modules
and are not responsible for the consequences of their installation;
the packages are compiled based on numerous requests
exclusively for user convenience. Module Version Packages If the module you need is not in the list, you can build it yourself for the
Angie or Angie PRO that you installed from our packages. Angie and
Angie PRO load a dynamic module only if it was built: for the same product, Angie or Angie PRO; for exactly the same version; with matching build options. Our packages are built without the The steps use ngx-fancyindex
as the example: an arbitrarily chosen module that is not in our list. Other
modules take the same steps with their own repository address and module
names, plus any libraries or modules that their own build instructions
require. We do not review the code of modules built this way and are not responsible
for the consequences of loading them. Install the compiler, the libraries that Angie is built with, and the tools
for getting the source code. On Debian and Ubuntu: On RHEL, Fedora, and derivatives, also install Angie PRO only: install On RHEL, Fedora, and derivatives: Download and unpack the Angie source code of the installed version. For
Angie PRO, this is the source code of Angie of the same version; the
Angie PRO files are added to it in step 6. Angie PRO prints its version
with a Clone the module's repository next to the Angie source tree; in the
example, it is ngx-fancyindex: Configure the build with the options of the installed Angie or Angie PRO,
adding the module. On RHEL, Fedora, and derivatives, first set the
distribution's standard compiler flags, which our packages are also built
with but Then, on any distribution, run: eval makes the shell honor the quotes in the printed options, so
values with spaces stay whole. The second sed removes
If ./configure fails, fix the cause, for example by installing a
missing library, and delete the On RHEL, Fedora, and derivatives, the errors from a skipped step do not name
it: without Angie PRO only: replace the header files and the build configuration of the
source tree with those of Angie PRO: The package mirrors the layout of the Build the module: The result is the Install the module: For Angie and Angie PRO alike, load the module with the load_module
directive in the If the module does not match the installed Angie or Angie PRO,
Every new version of Angie or Angie PRO requires rebuilding the module: it
rejects a build for the previous version with the version error. If the
service is running when the package is upgraded to a new version, the package
tries to switch it to the new executable on the fly. With the module built for
the previous version, the new executable rejects the configuration, so the
switch does not happen: the package prints a After the upgrade, rebuild and reinstall the module, reusing its source code
from the first build: repeat steps 3 and 5 to 8, starting in the directory
where you ran step 3 for the first build; for Angie PRO, repeat step 2 first.
The last step uses install, not cp, because
install writes a new file instead of overwriting the one that the
running service has loaded. Then restart the service so that the new
executable starts with the rebuilt module: A reload is not enough here: it succeeds, but the running executable keeps
working with the module build it has already loaded. To switch to the new
executable and the rebuilt module without interrupting service, use an
on-the-fly upgrade instead of a restart.Installation and Configuration#
main context:load_module modules/<module_name>.so;
angie-module-<name>angie-pro-module-<name>List of Packages#
angie-module-auth-jwtangie-pro-module-auth-jwtangie-module-auth-ldapangie-pro-module-auth-ldapangie-module-auth-pamangie-pro-module-auth-pamangie-module-auth-spnegoangie-pro-module-auth-spnegoangie-module-auth-totpangie-pro-module-auth-totpangie-module-brotliangie-pro-module-brotliangie-module-cache-purgeangie-pro-module-cache-purgeangie-module-cgiangie-pro-module-cgiangie-module-combined-upstreamsangie-pro-module-combined-upstreamsangie-module-dav-extangie-pro-module-dav-extangie-module-dynamic-limit-reqangie-pro-module-dynamic-limit-reqangie-module-echoangie-pro-module-echoangie-module-enhanced-memcachedangie-pro-module-enhanced-memcachedangie-module-evalangie-pro-module-evalangie-module-geoip2angie-pro-module-geoip2angie-module-headers-moreangie-pro-module-headers-moreangie-module-http-auth-radiusangie-pro-module-http-auth-radiusangie-module-jwtangie-pro-module-jwtangie-module-keyvalangie-pro-module-keyvalangie-module-luaangie-pro-module-luaangie-module-modsecurityangie-pro-module-modsecurityangie-module-njsangie-pro-module-njsangie-module-ndkangie-pro-module-ndkangie-module-oidcangie-pro-module-oidcangie-module-opentracingangie-pro-module-opentracingangie-module-otelangie-pro-module-otelangie-module-postgresangie-pro-module-postgresangie-module-redis2angie-pro-module-redis2angie-module-rtmpangie-pro-module-rtmpangie-module-set-miscangie-pro-module-set-miscangie-module-subsangie-pro-module-subsangie-module-testcookieangie-pro-module-testcookieangie-module-unbrotliangie-pro-module-unbrotliangie-module-unzstdangie-pro-module-unzstdangie-module-uploadangie-pro-module-uploadangie-module-vodangie-pro-module-vodangie-module-vtsangie-pro-module-vtsangie-module-weserv-imagesangie-pro-module-weserv-imagesangie-module-zipangie-pro-module-zipangie-module-zstdangie-pro-module-zstdBuilding a Module for the Packaged Version of Angie or Angie PRO#
--with-compat option, so the
packaged Angie and Angie PRO reject a module built with the default
./configure options or with --with-compat. The
procedure below builds a module that the packaged Angie or Angie PRO loads.
You do not rebuild or replace Angie or Angie PRO itself: the package stays
installed, and the module is built separately and loaded into it. The module
is built in the Angie source tree of the same version as the installed
package, with the build options of that package. Angie PRO ships only as
binary packages, without source code, but it uses the same build system as
Angie. To build a module for Angie PRO, you use the same Angie source tree
with the header files and the build configuration of Angie PRO from the
angie-pro-headers package.$ sudo apt install build-essential libpcre2-dev zlib1g-dev libssl-dev libcrypt-dev curl git
redhat-rpm-config,
which provides the compiler settings that our packages are built with:$ sudo dnf install gcc make pcre2-devel zlib-devel openssl-devel libxcrypt-devel redhat-rpm-config git
angie-pro-headers of the same version as
the installed angie-pro package. The angie-pro-headers
package installs the header files and the build configuration of
Angie PRO into /usr/include/angie-pro/. It comes from the same
repository as angie-pro, and its availability depends on your
license. It does not depend on angie-pro,
so the package manager does not match their versions; specify the version
explicitly. On Debian and Ubuntu:$ sudo apt install "angie-pro-headers=$(dpkg-query -W -f='${Version}' angie-pro)"
$ sudo dnf install "angie-pro-headers-$(rpm -q --qf '%{VERSION}-%{RELEASE}' angie-pro)"
(PRO) suffix, which the first command drops:$ VERSION=$(sudo angie -v 2>&1 | sed -n 's|^Angie version: Angie/\([0-9.]*\).*|\1|p')
$ echo "$VERSION"
1.12.4
$ curl -fsSO "https://download.en.angie.software/files/angie-$VERSION.tar.gz"
$ tar -xzf "angie-$VERSION.tar.gz"
$ git clone https://github.com/aperezdc/ngx-fancyindex
angie -V does not show:$ export CFLAGS="$(rpm --eval '%{optflags}')"
$ cd "angie-$VERSION"
$ eval ./configure $(sudo angie -V 2>&1 | sed -n 's/^configure arguments: //p' | sed 's/ --with-license//') \
--add-dynamic-module=../ngx-fancyindex
--with-license, which some Angie PRO packages are built with:
Angie's ./configure does not know this option, and the option
affects only the Angie PRO executable, not the module. For Angie, the
options do not contain it.../angie-feature-cache directory
before running it again: the package options include
--feature-cache=../angie-feature-cache, so ./configure
saves failed checks there and reports them on the next run as
using cached check ... not found.redhat-rpm-config, ./configure stops with
the invalid value in --with-ld-opt="value", and without the
exported CFLAGS, with C99 variadic macros support is not found.$ cp -r /usr/include/angie-pro/. src/
$ cp src/objs/* objs/
src directory, so the first
command replaces the header files. The package's objs
subdirectory, now at src/objs, holds the build configuration of
Angie PRO (ngx_auto_config.h and ngx_auto_headers.h); the
second command copies those files into the objs directory that
./configure created. Both commands are needed. The header files
give the module the structures and the product signature of Angie PRO.
The build configuration sets the build options the module is compiled
with: Angie PRO has options that Angie's ./configure does not
know, and a module compiled with Angie's configuration would not match
the layout of the Angie PRO structures.$ make modules
objs/ngx_http_fancyindex_module.so file.$ sudo install -m 644 objs/ngx_http_fancyindex_module.so /etc/angie/modules/
Loading and Upgrading#
main context, then check and reload the
configuration:load_module modules/ngx_http_fancyindex_module.so;
$ sudo angie -t && sudo systemctl reload angie
angie -t fails with a message that names the mismatch:module "file" was built for "Angie" but you are running "Angie PRO",
or the same with the products swapped — the module was built for the other
product;module "file" version module_version instead of angie_version —
the module was built for another version; each version is printed as a
single integer, with the minor version and the patch number zero-padded to
three digits;module "file" is not binary compatible — the module was built with
other build options.Binary upgrade failed
message, and the previous executable keeps serving.$ sudo angie -t && sudo systemctl restart angie
Content