Upgrading the postanalytics module¶
These instructions describe the steps to upgrade the postanalytics module 4.x installed on a separate server. Postanalytics module must be upgraded before Upgrading Wallarm NGINX modules.
To upgrade the end‑of‑life module (3.6 or lower), please use the different instructions.
Upgrade methods¶
You can upgrade in two different ways:
-
Migrate to the all-in-one installer usage during the upgrade procedure. This is the recommended approach as it automates various node installation and upgrade activities, such as NGINX and OS version identification, adding appropriate Wallarm repositories, installing packages, and others.
-
Keep using the current manual installation method via individual DEB/RPM packages. However, it's important to note that in further upgrades this approach will require additional effort and manual configuration in comparison to the new method.
Upgrade with all-in-one installer¶
Use the procedure below to upgrade the postanalytics module 4.x installed on a separate server to version 4.6 using all-in-one installer.
Requirements for upgrade using all-in-one installer¶
-
Access to the account with the Administrator role in Wallarm Console for the US Cloud or EU Cloud.
-
Access to
https://meganode.wallarm.com
to download all-in-one Wallarm installer. Ensure the access is not blocked by a firewall. -
Access to
https://us1.api.wallarm.com
for working with US Wallarm Cloud or tohttps://api.wallarm.com
for working with EU Wallarm Cloud. If access can be configured only via the proxy server, then use the instructions. -
Executing all commands as a superuser (e.g.
root
).
Step 1: Prepare clean machine¶
When upgrading modules 4.x or lower to 4.6 with all-in-one installer, you cannot upgrade an old package installation - instead you need to use a clean machine. Thus, as step 1, prepare a machine with one of the supported OS:
-
Debian 10, 11 and 12.x
-
Ubuntu LTS 18.04, 20.04, 22.04
-
CentOS 7, 8 Stream, 9 Stream
-
Alma/Rocky Linux 9
-
Oracle Linux 8.x
-
Redos
-
SuSe Linux
-
Others (the list is constantly widening, contact Wallarm support team to check if your OS is in the list)
Using new clean machine will lead to that at some moment you will have both old and new node, which is good: you can test the new one working properly without stopping the old one.
Step 2: Prepare Wallarm token¶
To install node, you will need a Wallarm token of the appropriate type. To prepare a token:
Step 3: Download all-in-one Wallarm installer¶
Wallarm suggests all-in-one installations for the following processors:
-
x86_64
-
ARM64 (beta)
To download all-in-one Wallarm installation script, execute the command:
curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.12.x86_64-glibc.sh
curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.12.aarch64-glibc.sh
Step 4: Run all-in-one Wallarm installer to install postanalytics¶
To install postanalytics separately with all-in-one installer, use:
# If using the x86_64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.6.12.x86_64-glibc.sh postanalytics
# If using the ARM64 version:
sudo env WALLARM_LABELS='group=<GROUP>' sh wallarm-4.6.12.aarch64-glibc.sh postanalytics
The WALLARM_LABELS
variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI).
# If using the x86_64 version:
sudo sh wallarm-4.6.12.x86_64-glibc.sh postanalytics
# If using the ARM64 version:
sudo sh wallarm-4.6.12.aarch64-glibc.sh postanalytics
Step 5: Upgrade the NGINX-Wallarm module on a separate server¶
Once the postanalytics module is installed on the separate server, upgrade its related NGINX-Wallarm module running on a different server.
Combining upgrade methods
Both manual and automatic approaches can be used to upgrade the related NGINX-Wallarm module.
Step 6: Re-connect the NGINX-Wallarm module to the postanalytics module¶
On the machine with the NGINX-Wallarm module, in the NGINX configuration file, specify the postanalytics module server address:
upstream wallarm_tarantool {
server <ip1>:3313 max_fails=0 fail_timeout=0 max_conns=1;
server <ip2>:3313 max_fails=0 fail_timeout=0 max_conns=1;
keepalive 2;
}
# omitted
wallarm_tarantool_upstream wallarm_tarantool;
-
max_conns
value must be specified for each of the upstream Tarantool servers to prevent the creation of excessive connections. -
keepalive
value must not be lower than the number of the Tarantool servers. -
The
# wallarm_tarantool_upstream wallarm_tarantool;
string is commented by default - please delete#
.
Once the configuration file changed, restart NGINX/NGINX Plus on the NGINX-Wallarm module server:
sudo systemctl restart nginx
sudo service nginx restart
sudo systemctl restart nginx
sudo systemctl restart nginx
Step 7: Check the NGINX‑Wallarm and separate postanalytics modules interaction¶
To check the NGINX‑Wallarm and separate postanalytics modules interaction, you can send the request with test attack to the address of the protected application:
curl http://localhost/etc/passwd
If the NGINX‑Wallarm and separate postanalytics modules are configured properly, the attack will be uploaded to the Wallarm Cloud and displayed in the Events section of Wallarm Console:
If the attack was not uploaded to the Cloud, please check that there are no errors in the services operation:
-
Make sure that the postanalytics service
wallarm-tarantool
is in the statusactive
sudo systemctl status wallarm-tarantool
-
Analyze the postanalytics module logs
sudo cat /var/log/wallarm/tarantool.log
If there is the record like
SystemError binary: failed to bind: Cannot assign requested address
, make sure that the server accepts connection on specified address and port. -
On the server with the NGINX‑Wallarm module, analyze the NGINX logs:
sudo cat /var/log/nginx/error.log
If there is the record like
[error] wallarm: <address> connect() failed
, make sure that the address of separate postanalytics module is specified correctly in the NGINX‑Wallarm module configuration files and separate postanalytics server accepts connection on specified address and port. -
On the server with the NGINX‑Wallarm module, get the statistics on processed requests using the command below and make sure that the value of
tnt_errors
is 0curl http://127.0.0.8/wallarm-status
Description of all parameters returned by the statistics service →
Step 8: Remove old postanalytics module¶
-
Delete old postanalytics module in Wallarm Console → Nodes by selecting your postanalytics module node and clicking Delete.
-
Confirm the action.
When the postanalytics module node is deleted from Cloud, it will stop participation in filtration of requests to your applications. Deleting cannot be undone. The postanalytics module node will be deleted from the list of nodes permanently.
-
Delete machine with the old postanalytics module or just clean it from Wallarm postanalytics module components:
sudo apt remove wallarm-node-tarantool
sudo apt remove wallarm-node-tarantool
sudo yum remove wallarm-node-tarantool
sudo yum remove wallarm-node-tarantool
Manual upgrade¶
Use the procedure below to manually upgrade the postanalytics module 4.x installed on a separate server to version 4.6.
Requirements¶
-
Access to the account with the Administrator role in Wallarm Console in the US Cloud or EU Cloud
-
Access to
https://us1.api.wallarm.com
if working with US Wallarm Cloud or tohttps://api.wallarm.com
if working with EU Wallarm Cloud. Please ensure the access is not blocked by a firewall
Step 1: Add new Wallarm repository¶
Delete the previous Wallarm repository address and add a repository with a new Wallarm node version packages. Please use the commands for the appropriate platform.
CentOS and Amazon Linux 2.0.2021x and lower
sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm
sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm
Debian and Ubuntu
-
Open the file with the Wallarm repository address in the installed text editor. In this instruction, vim is used.
sudo vim /etc/apt/sources.list.d/wallarm.list
-
Comment out or delete the previous repository address.
-
Add a new repository address:
Unsupported by NGINX stable and NGINX Plus
Official NGINX versions (stable and Plus) and, as a result, Wallarm node 4.4 and above cannot be installed on Debian 10.x (buster). Please use this OS only if NGINX is installed from Debian/CentOS repositories.
deb https://repo.wallarm.com/debian/wallarm-node buster/4.6/
deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/
deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.6/
deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/
Step 2: Upgrade the Tarantool packages¶
sudo apt update
sudo apt dist-upgrade
The error "signatures couldn't be verified"
If added GPG keys expired, the following error would be returned:
W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
To fix the problem, please import new GPG keys for the Wallarm packages and then upgrade the packages using the following commands:
curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sudo apt update
sudo apt dist-upgrade
Upgrading Wallarm dependencies
The sudo apt dist-upgrade
command upgrades both the Wallarm packages and filtering node dependencies. It is the recommended upgrade option providing correct operation of the newer filtering node version.
sudo apt update
sudo apt dist-upgrade
The error "signatures couldn't be verified"
If added GPG keys expired, the following error would be returned:
W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
To fix the problem, please import new GPG keys for the Wallarm packages and then upgrade the packages using the following commands:
curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add -
sudo apt update
sudo apt dist-upgrade
Upgrading Wallarm dependencies
The sudo apt dist-upgrade
command upgrades both the Wallarm packages and filtering node dependencies. It is the recommended upgrade option providing correct operation of the newer filtering node version.
sudo yum update
sudo yum update
Step 3: Update the node type¶
Only for nodes installed using the addnode
script
Only follow this step if a node of a previous version is connected to the Wallarm Cloud using the addnode
script. This script has been removed and replaced by the register-node
, which requires a token to register the node in the Cloud.
-
Make sure that your Wallarm account has the Administrator role by navigating to the user list in the US Cloud or EU Cloud.
-
Open Wallarm Console → Nodes in the US Cloud or EU Cloud and create the node of the Wallarm node type.
-
Copy the generated token.
-
Execute the
register-node
script to run the node:sudo /usr/share/wallarm-common/register-node -t <TOKEN> -H us1.api.wallarm.com --force --no-sync --no-sync-acl
sudo /usr/share/wallarm-common/register-node -t <TOKEN> --force --no-sync --no-sync-acl
<TOKEN>
is the copied value of the node token or API token with theDeploy
role.- The
--force
option forces rewriting of the Wallarm Cloud access credentials specified in the/etc/wallarm/node.yaml
file.
Using one token for several installations
You have two options for using one token for several installations:
- For all node versions, you can use one node token in several installations regardless of the selected platform. It allows logical grouping of node instances in the Wallarm Console UI. Example: you deploy several Wallarm nodes to a development environment, each node is on its own machine owned by a certain developer.
Starting from node 4.6, for nodes grouping, you can use one API token with the
Deploy
role together with the--labels 'group=<GROUP>'
flag, for example:
sudo /usr/share/wallarm-common/register-node -t <API TOKEN WITH DEPLOY ROLE> --labels 'group=<GROUP>'
Step 4: Restart the postanalytics module¶
sudo systemctl restart wallarm-tarantool
sudo service wallarm-tarantool restart
sudo systemctl restart wallarm-tarantool
sudo systemctl restart wallarm-tarantool