If you use Fail2Ban with Nginx and WordPress, sooner or later you’ll notice one thing: the same IP addresses keep coming back. They get banned for a few minutes or an hour, disappear… and shortly after try again /.env, /wp-login.php, /phpmyadmin, or other common attack paths.

The solution is not to aggressively tighten the filters. The solution is recidive — a second layer of protection in Fail2Ban that analyzes the ban history and blocks repeat offenders long-term.

Reference to the previous configuration

If you don’t yet have a basic Fail2Ban configuration for Nginx and WordPress, I described it here:

Fail2Ban + Nginx + WordPress – basic configuration

In that article, we configure jails such as nginx-exploit, nginx-secure, and sshd. Recidive does not replace that configuration — it strengthens it.

How to find repeat offenders in the logs

First, it’s worth checking whether the issue actually exists. We extract from the Fail2Ban logs the list of IP addresses that were banned most frequently:

grep "Ban " /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head

Example output (addresses partially anonymized):

13 204.76.203.18
9 41.142.XXX.XXX
8 64.89.XXX.XXX
8 50.82.XXX.XXX
8 35.243.XXX.XXX
8 34.24.XXX.XXX
7 45.166.XXX.XXX
7 34.83.XXX.XXX
7 176.42.XXX.XXX
6 49.36.XXX.XXX

If you see numbers like 8, 9, or 13 — it means those IPs are coming back after the ban expires. A short bantime is just a technical pause for them.

Why recidive is better than increasing bantime

• You don’t have to ban everyone for 24 hours because of a single typo in a URL.
• You don’t increase the risk of blocking legitimate users.
• The penalty is progressive and applies only to returning addresses.

Recidive analyzes /var/log/fail2ban.log and counts how many times a given IP has been banned by other jails. This way, you only “finish off” those that have already been blocked multiple times before.

Recidive configuration (5 bans in 24h = 7 days ban)

Add the following block to /etc/fail2ban/jail.local:

nano /etc/fail2ban/jail.local

At the end of the file, paste:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 7d
findtime = 1d
maxretry = 5

Save the file and restart Fail2Ban:

systemctl restart fail2ban

Check the jail status:

fail2ban-client status recidive

How to check who is close to the recidive threshold

If you want to see IPs that already have several bans and are approaching the recidive threshold:

grep "Ban " /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | awk '$1 >= 3 {print}' | sort -nr

Summary

Recidive is one of the simplest and most effective ways to limit recurring scanners and bots. Instead of aggressively banning everyone — you block only those who repeatedly come back.

In an environment with multiple domains, Nginx reverse proxy, and WordPress, it’s practically a must-have configuration element: less noise in logs, fewer repeated attacks, and less manual analysis.

Artykuł Fail2Ban: How to Detect Repeat Offenders and Ban Them for a Week (Recidive) pochodzi z serwisu soban.

The Linux system is a powerful tool that offers users tremendous flexibility and control over their working environment. However, to fully harness its potential, it is worth knowing the key commands that are essential for both beginners and advanced users. In this article, we will present and discuss the most important Linux commands that every user should know.

1. Basic Navigation Commands

• pwd – Displays the current directory path you are in:

pwd

• ls – Lists the contents of a directory. You can use the -l option for a detailed view or -a to show hidden files:

ls -a

• cd – Changes the directory. For example, cd /home/user will move you to the /home/user directory:

cd ~

• mkdir – Creates a new directory:

mkdir projects

• rmdir – Removes an empty directory:

rmdir old_files

2. File Management

• cp – Copies files or directories:

cp document.txt new_directory/

• mv – Moves or renames files/directories:

mv file.txt /home/user/new_directory/

• rm – Removes files or directories. Use the -r option to remove a directory with its contents:

rm -r old_data

• touch – Creates an empty file or updates the modification time of an existing file:

touch report.txt

3. Process Management

• ps – Displays currently running processes. Use the -aux option to see all processes:

ps -aux

• top – Displays a dynamic list of processes in real time:

top

• kill – Stops a process by its ID:

kill 1234

• bg and fg – Manage background and foreground processes:

fg

4. User and Permission Management

• sudo – Allows a command to be executed with administrator privileges:

sudo apt update

• chmod – Changes permissions for files/directories:

chmod 755 script.sh

• chown – Changes the owner of a file/directory:

chown admin:admin file.txt

• useradd and userdel – Adds and removes users:

useradd janek

5. Networking and Communication

• ping – Checks the connection with another host:

ping 192.168.1.1

• ifconfig – Displays information about network interfaces:

ifconfig

• ssh – Connects remotely to another computer:

ssh user@192.168.1.2

• scp – Copies files over SSH:

scp file.txt user@host:/home/user/

6. Command Usage Examples

Below is an example of using several discussed commands:

• chmod – Changes permissions for files/directories:

chmod 755 script.sh

• chown – Changes the owner of a file/directory:

chown admin:developers logs.txt

• useradd and userdel – Adds and removes users:

useradd janek

7. Disk and File System Management

• df – Displays information about disk space availability:

df -h

• du – Shows the size of files and directories:

du -sh documents

• mount – Mounts a file system:

mount /dev/sdb1 /mnt/external

• umount – Unmounts a file system:

umount /mnt/external

8. Searching for Files

• find – Searches for files in the system:
• locate – Quickly searches for files in the system:
• grep – Searches for patterns in files:
• which – Finds the full path to an executable file:

9. Communicating with the System

• echo – Displays text on the screen:
• cat – Displays the contents of a file:
• more – Displays the contents of a file page by page:
• less – Similar to more, but offers more navigation options:
• man – Displays the user manual for a command:

10. Working with Archives

• tar – Creates or extracts archives:
• zip – Creates a ZIP archive:
• unzip – Extracts ZIP files:
• tar -xvzf – Extracts a TAR.GZ archive:
• gzip – Compresses files in .gz format:
• gunzip – Extracts .gz files:

11. System Monitoring

• uptime – Displays the system uptime and load:
• dmesg – Displays system messages related to boot and hardware:
• iostat – Shows input/output system statistics:
• free – Displays information about RAM:
• netstat – Displays information about network connections:
• ss – A modern version of netstat, used for monitoring network connections:

12. Working with System Logs

• journalctl – Reviews system logs:
• tail – Displays the last lines of a file:
• logrotate – Automatically manages logs:

13. Advanced File Operations

• ln – Creates a link to a file:
• xargs – Passes arguments from input to other commands:
• chmod – Changes permissions for files/directories:
• chattr – Changes file attributes:

Linux offers a wide array of commands that allow for complete control over the computer. Key commands such as ls, cd, cp, and rm are used daily to navigate through the file system, manage files, and directories. To effectively master these commands, it’s best to start with those that are most useful in everyday work. For instance, commands for navigating directories and managing files are fundamental and require practice to become intuitive. Other commands, such as ps for monitoring processes, ping for testing network connections, or chmod for changing permissions, are also worth knowing to fully leverage the power of the Linux system.

To learn effectively, it’s advisable to start by experimenting with commands in practice. Creating files, directories, copying, and deleting data allows for familiarity with their operation. Over time, it’s worthwhile to start combining different commands to solve more advanced problems, such as monitoring processes, managing users, or working with system logs. One can also use documentation, such as man or websites, to delve into the details of each command and its options.

Remember, regular use of the terminal allows for learning habits that make handling the Linux system more natural. Frequent use of commands, solving problems, and experimenting with new commands is the best way to master the system and fully utilize it.

Linux is indeed a powerful tool that provides great control over the system… but remember, don’t experiment on production! After all, experimenting on a production server is a bit like playing Russian roulette — only with bigger consequences. If you want to feel like a true Linux wizard, always test your commands in a development environment. Only then will you be able to learn from mistakes instead of searching for the cause of several gigabytes of data disappearance. And if you don’t know what you’re doing, simply summon your trusty weapon: man!

Artykuł The most important Linux commands that every user should know pochodzi z serwisu soban.

Automation of Disk Space Management in a Linux Environment

In today’s digital world, where data is being accumulated in ever-increasing amounts, managing disk space has become a key aspect of maintaining operational efficiency in systems. In this article, I will present a script that automates the process of managing space on a remote disk mounted via SSHFS, particularly useful for system administrators who regularly deal with filling storage media.

Prerequisites

Before starting, ensure that SSHFS and all necessary packages enabling its proper operation are installed on your system. SSHFS allows remote file systems to be mounted via SSH, which is crucial for our script’s operation. To install SSHFS and the necessary tools, including a package that enables password forwarding (sshpass), use the following command:

apt-get update
apt-get install sshfs fuse sshpass -y

Bash Script for Disk Space Management

Our Bash script focuses on monitoring and maintaining a defined percentage of free disk space on a remote disk mounted via SSHFS. Here are the script’s main functions:

Goal Definition:

TARGET_USAGE=70 – the percentage of disk space we want to maintain as occupied. The script will work to keep at least 30% of the disk space free.

Mount Point and Paths:

MOUNT_POINT=”/mnt/qnapskorupki” – the local directory where the remote disk is mounted. TARGET_DIRS=”$MOUNT_POINT/up*.soban.pl” – the directories where the script will look for files to delete if needed.

Function check_qnap: This function checks whether the disk is mounted and whether the mount directory is not empty. If there are issues, the script attempts to unmount and remount the disk using sshfs with a password forwarded through sshpass.

File Deletion: The script monitors disk usage and, if TARGET_USAGE is exceeded, it finds and deletes the oldest files in specified directories until the target level of free space is achieved.

#!/bin/bash

TARGET_USAGE=70
MOUNT_POINT="/mnt/qnapskorupki"
TARGET_DIRS="$MOUNT_POINT/up*.soban.pl"

# Function to check and mount SSHFS
function check_qnap {
    local remote_path="/share/MD0_DATA/backup_proxmox/"
    local user_remote="remote_user"
    local remote_host="192.168.1.XX"
    local port=22
    local password='XXXXXXXXXXXXXXXXXXXXXXX'

    # Check if the mounting directory exists and is empty
    if [ ! -d "$MOUNT_POINT" ] || [ -z "$(ls -A $MOUNT_POINT)" ]; then
        echo "Problem: The directory $MOUNT_POINT is missing or empty. Attempting to remount..."

        # Unmount if anything is currently mounted
        if mountpoint -q $MOUNT_POINT; then
            echo "Unmounting $MOUNT_POINT..."
            fusermount -u $MOUNT_POINT
            sleep 5
        fi

        # Remount
        echo "Mounting SSHFS: $user_remote@$remote_host:$remote_path to $MOUNT_POINT..."
        echo $password | sshfs $user_remote@$remote_host:$remote_path $MOUNT_POINT -o password_stdin

        # Check if the mounting was successful
        if mountpoint -q $MOUNT_POINT; then
            echo "QNAP successfully mounted."
        else
            echo "Error: Failed to mount $remote_host:$remote_path to $MOUNT_POINT."
            exit 1
        fi
    fi
}

# Check and mount the disk
check_qnap

# Begin deleting files
current_usage=$(df --output=pcent "$MOUNT_POINT" | tail -n 1 | tr -d '%')
echo "Current usage: $current_usage%"
target_free_space=$((100 - $TARGET_USAGE))

# Continue deleting files until the required free space is achieved
while [[ $current_usage -gt $TARGET_USAGE ]]; do
    # Find the oldest file in the target directories
    oldest_file=$(find $TARGET_DIRS -type f -printf '%T+ %p\n' | sort | head -n 1 | cut -d' ' -f2)

    if [ -z "$oldest_file" ]; then
        echo "No files to delete."
        break
    fi

    # Delete the oldest file
    echo "Deleting file $oldest_file..."
    rm -f "$oldest_file"

    # Check usage again
    current_usage=$(df --output=pcent "$MOUNT_POINT" | tail -n 1 | tr -d '%')
    echo "New usage after deletion: $current_usage%"
done

echo "Target disk usage achieved."

Example Script Execution:

The script will run until it reaches 70% usage as planned:

Downloading the script and adding it to crontab

Of course, the script should be adjusted to meet your specific needs. However, if you want to download it and add it to crontab, follow these steps:

wget soban.pl/bash/remove_old_files.sh
chmod +x remove_old_files.sh

If you want to automate the file removal process, for example, at the end of the day, add the following entry to crontab:

crontab -e

In this case, the script will run every day at 11:55 PM:

45 23 * * * /root/scripts/remove_old_files.sh > /dev/null 2>&1

Make sure to use the correct path to the script.

Security and Optimization

The script uses a password directly in the command line, which can pose a security risk. In practical applications, it is recommended to use more advanced authentication methods, such as SSH keys, which are more secure and do not require a plaintext password in the script. However, in the case of QNAP, we used a password when writing this script.

Conclusion

The presented script is an example of how daily administrative tasks, such as disk space management, can be automated, thus increasing efficiency and reliability. Its implementation in real IT environments can significantly streamline data management processes, especially in situations where quick response to changes in disk usage is critical.

Artykuł Automatic deletion of files on QNAP drive via SSHFS pochodzi z serwisu soban.

Automatically Shutting Down Your Laptop at Low Battery Levels

Maintaining long battery life and protecting data are crucial for laptop users. In this article, we’ll show you how to create a simple Bash script that automatically shuts down your laptop when the battery level falls below 20%. Additionally, you’ll learn how to set up a crontab to run the script every 10 minutes, ensuring continuous monitoring.

Creating a Bash Script

The Bash script we have prepared will check the current battery level and compare it to a set minimum threshold. If the battery level drops below this threshold, the script initiates a system shutdown, helping to protect your data and hardware.

#!/bin/bash

# Define the minimum battery level before shutdown
MIN_BATTERY_LEVEL=20

# Get the current battery level
current_level=$(cat /sys/class/power_supply/BAT0/capacity)

# Check if the current battery level is less than or equal to the minimum level
if [[ "$current_level" -le "$MIN_BATTERY_LEVEL" ]]; then
  echo "Battery level is $current_level%, which is below the threshold of $MIN_BATTERY_LEVEL%. Shutting down..."
  # Shutdown command
  /sbin/shutdown -h now
else
  echo "Battery level is $current_level%, no need to shut down."
fi

Also you can download script:

wget https://soban.pl/bash/check_battery.sh

Don’t forget to grant permissions to run it:

chmod +x check_battery.sh

Crontab Configuration

Crontab is a tool that allows you to schedule tasks in the Linux system. With it, we can set up regular battery checks.

crontab -e

# Add the following line to crontab to run the script every 10 minutes
*/10 * * * * /root/check_battery.sh > /dev/null 2>&1

Summary

With this setup, you can rest assured about the condition of your laptop even during intensive use. Automatic shutdown at low battery levels not only protects the equipment but also helps maintain a longer battery life.

Artykuł How to automatically turn off your laptop when battery status is displayed in Linux pochodzi z serwisu soban.

Managing Proxmox clusters can sometimes present technical difficulties, such as inconsistencies in cluster configuration or issues with restoring LXC containers. Finding and resolving these issues is crucial for maintaining the stability and performance of the virtualization environment. In this article, I present a detailed guide on how to diagnose and resolve an issue with an unreachable node and how to successfully restore an LXC container.

Before you begin any actions, make sure you have a current backup of the system.

Diagnosing the State of the Proxmox Cluster

pvecm delnode up-page-02
Node/IP: up-page-02 is not a known host of the cluster.

and:

pct restore 107 vzdump-lxc-107-2024_11_12-03_00_01.tar.zst --storage local
CT 107 already exists on node 'up-page-02'

To understand the state of the cluster, execute the following command on the node-up-page-04 node:

pvecm nodes

Expected output:

Membership information
----------------------
    Nodeid      Votes Name
         1          1 node-up-page-01
         2          1 node-up-page-04 (local)

Then check the detailed cluster information with the following command:

pvecm status

Expected output:

Cluster information
-------------------
Name:             soban-proxmox
Config Version:   4
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Wed Nov 13 10:40:12 2024
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1.e6
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 <masked IP>
0x00000002          1 <masked IP> (local)

Removing the Container Configuration File and Cleaning Data

I discovered that the configuration file for container 107 still exists on the cluster’s file system at the path:

ls -ltr /etc/pve/nodes/node-up-page-02/lxc/107.conf

Output:

-rw-r----- 1 root www-data 235 Nov 12 21:35 /etc/pve/nodes/node-up-page-02/lxc/107.conf

To remove this file and any remaining data associated with the detached node, execute:

rm -rf /etc/pve/nodes/node-up-page-02/

Restoring the Container

After removing the configuration file, I restored the LXC container on the node-up-page-04 node using the command:

pct restore 107 /root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst --storage local

Output:

recovering backed-up configuration from '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst'
Formatting '/var/lib/vz/images/107/vm-107-disk-0.raw', fmt=raw size=59055800320 preallocation=off
Creating filesystem with 14417920 4k blocks and 3604480 inodes
Filesystem UUID: 8b707e55-5e14-4b20-8585-6cb09e0fa520
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424
restoring '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst' now..
extracting archive '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst'

The restoration process was successful, and the container was ready for use. This case illustrates the importance of thorough diagnostics and configuration file management in Proxmox when working with clusters. Regular reviews of configurations are advisable to avoid inconsistencies and operational issues in the future.

Artykuł Troubleshooting Proxmox clusters and restoring the LXC container pochodzi z serwisu soban.

Virtualization servers based on Debian family systems, such as Proxmox, are often used in test environments where continuous availability is crucial. Sometimes these servers are installed on laptops, which serve as low-budget or portable solutions. However, the standard power management settings in laptops can lead to undesirable behaviors, such as sleeping or hibernating when the lid is closed. Below, I describe how to change these settings in an operating system based on Debian to ensure uninterrupted server operation.

Step 1: Accessing the Configuration File

Open the terminal and enter the following command to edit the /etc/systemd/logind.conf file using a text editor (e.g., nano):

nano /etc/systemd/logind.conf

Step 2: Modifying logind Settings

Find the line containing HandleLidSwitch and change its value to ignore. If the line is commented out (preceded by a # symbol), remove the #. You can also add this line to the end of the file if it does not exist.

HandleLidSwitch=ignore

Step 3: Applying and Restarting the Service

After making the changes and saving the file, you need to restart the systemd-logind service for the changes to take effect. Use the following command in the terminal:

systemctl restart systemd-logind

With these changes, closing the laptop lid will no longer initiate hibernation or sleep, which is especially important when using Debian-based servers, including Proxmox, as server solutions.

Artykuł How to prevent hibernation and sleep on debian and proxmox laptops when the lid is closed pochodzi z serwisu soban.

Introduction

Managing SWAP memory is a key element in administering Linux operating systems, especially in virtualization environments like Proxmox. SWAP acts as “virtual memory” that can be used when the system’s physical RAM is full. In this article, we will show how to increase SWAP space on a Proxmox server, using the lvresize tool to free up disk space that can then be allocated to SWAP.

Problem Overview

A user wants to increase SWAP space from 8 GB to 16 GB, but encounters the problem of lacking available space in the LVM volume group, which is required to increase SWAP.

Step 1: Checking Available Space

vgs

The command vgs displays the volume groups along with their sizes and available space.

Step 2: Reducing the Volume

Suppose there is a root volume of 457.26 GB, which can be reduced to free up an additional 8 GB for SWAP. Before reducing the volume, it is necessary to reduce the file system on this volume.

resize2fs /dev/pve/root 449.26G

However, in the case of the XFS file system, reduction must occur offline or from a live CD.

Step 3: Using lvreduce

lvreduce -L -8G /dev/pve/root

This command reduces the root volume by 8 GB, which is confirmed by a message about the volume size change.

Step 4: Deactivating SWAP

swapoff -a

Before starting changes in SWAP size, SWAP must first be turned off using the above command.

Step 5: Expanding SWAP

lvresize -L +8G /dev/pve/swap
mkswap /dev/pve/swap
swapon /dev/pve/swap

The above commands first increase the SWAP space, then format it and reactivate it.

swapon --show

Finally, we verify the active SWAP areas using the above command to ensure everything is configured correctly.

This process shows how you can flexibly manage disk space on Proxmox servers, adjusting the size of SWAP depending on needs. Using lvreduce requires caution, as any operation on partitions and volumes carries the risk of data loss, therefore it is always recommended to make backups before proceeding with changes.

Artykuł Extending SWAP space on Proxmox using lvreduce pochodzi z serwisu soban.

Upgrading Apache Cassandra to a newer version is a significant task that database administrators undertake to ensure their systems benefit from new features, enhanced security measures, and improved performance. This guide provides a detailed walkthrough for upgrading Apache Cassandra from version 3.1.15 and higher to the latest 4.1.x version, specifically on Ubuntu 20.04.5 LTS, with an emphasis on pre-upgrade cleaning operations to manage disk space effectively.

Pre-upgrade Preparation

Backup Configuration Directory:

Before initiating the upgrade, it’s crucial to back up the Cassandra configuration directory. This precaution allows for a swift restoration of the configuration should any issues arise during the upgrade process. Utilize the following command to create a backup, incorporating the current date into the folder name for easy identification:

# cp -r /etc/cassandra/ /root/cassandra-conf-bkp-$(date +%Y%m%d)

Pre-Cleanup Operations

Preparation is key to a smooth upgrade. Begin with maintenance commands to guarantee data integrity and optimize space usage, especially important for systems with limited disk space.

Scrub Data:

Execute nodetool scrub to clean and reorganize data on disk. Given that this operation may be time-consuming, particularly for databases with large amounts of data or limited disk space, it’s a critical step for a healthy upgrade process.

Clear Snapshots:

To further manage disk space, use nodetool clearsnapshot to remove existing snapshots, freeing up space for the upgrade process. To delete all snapshots on the node, simply use this method if you’re running out of space:

# nodetool clearsnapshot --all

Cleanup Data:

Perform a nodetool cleanup to purge unnecessary data. In scenarios where disk space is a premium, it’s advisable to execute a scrub operation without generating a snapshot to conserve space:

# nodetool scrub --no-snapshot

Draining and Stopping Cassandra

Drain the Node:

Prior to halting the Cassandra service, ensure all data in memory is flushed to disk with nodetool drain.

# nodetool drain

Stop the Cassandra Service:

Cease the running Cassandra services to proceed with the upgrade safely:

# systemctl stop cassandra.service

Upgrading Cassandra

Update Source List:

Edit the repository sources to point to the new version of Cassandra by adjusting the cassandra.sources.list file:

# echo "deb https://debian.cassandra.apache.org 41x main" > /etc/apt/sources.list.d/cassandra.sources.list

Upgrade Packages:

With the repository sources updated, refresh the package list and upgrade the packages. When executing the apt upgrade command, you can keep pressing Enter as the default option is ‘N’ (No):

# apt update && apt upgrade

Modify Configuration:

Adjust the Cassandra configuration for version 4.1.x by commenting out or deleting deprecated options:

# for var in thrift_prepared_statements_cache_size_mb start_rpc rpc_port rpc_server_type thrift_framed_transport_size_in_mb request_scheduler; do sed -i "/$var:/s/^/#/" /etc/cassandra/cassandra.yaml; done

Update JAMM Library:

Ensure the Java Agent Memory Manager (JAMM) library is updated to enhance performance:

# sed -i 's|jamm-0.3.0.jar|jamm-0.3.2.jar|g' /etc/cassandra/cassandra-env.sh

Backup and update the JVM options file:

It’s a good practice to back up configuration files before making changes. This step renames the existing jvm-server.options file to jvm-server.options.orig as a backup. Then, it copies the jvm.options file to jvm-server.options to apply the standard JVM options for Cassandra servers.

# cd /etc/cassandra/
# mv jvm-server.options jvm-server.options.orig && cp -p jvm.options jvm-server.options

Optimization and Verification

Optimize Memory Usage:

Post-upgrade, it’s beneficial to evaluate and optimize memory usage and swap space to ensure efficient Cassandra operation:

# swapoff -a && swapon -a

Restart the Cassandra Service:

Apply the new version by restarting the Cassandra service:

# systemctl start cassandra.service

Verify Upgrade:

Confirm the success of the upgrade by inspecting the cluster’s topology and state, ensuring all nodes are functional:

# nodetool describecluster
# nodetool status

By adhering to this comprehensive guide, database administrators can effectively upgrade Apache Cassandra to version 4.1.x, capitalizing on the latest advancements and optimizations the platform has to offer, while ensuring data integrity and system performance through careful pre-upgrade preparations.

Optimization and Verification

After successfully upgrading Apache Cassandra to version 4.1.x and ensuring the cluster is fully operational, it’s crucial to conduct post-upgrade maintenance to optimize the performance and security of your database system. This section outlines essential steps and considerations to maintain a healthy and efficient Cassandra environment.

Monitor Performance and Logs

In the immediate aftermath of the upgrade, closely monitor the system’s performance, including CPU, memory usage, and disk I/O, to identify any unexpected behavior or bottlenecks. Additionally, review the Cassandra system logs for warnings or errors that may indicate potential issues requiring attention.

Tune and Optimize

Based on the performance monitoring insights, you may need to adjust Cassandra’s configuration settings for optimal performance. Consider tuning parameters related to JVM options, compaction, and read/write performance, keeping in mind the specific workload and data patterns of your application.

Run nodetool upgradesstables

To ensure that all SSTables are updated to the latest format, execute nodetool upgradesstables on each node in the cluster. This operation will rewrite SSTables that are not already in the current format, which is essential for taking full advantage of the improvements and features in Cassandra 4.1.x (Check the space, and if required, delete all snapshots as shown above.):

# time nodetool upgradesstables

This process can be resource-intensive and should be scheduled during off-peak hours to minimize impact on live traffic.

Implement Security Enhancements

Cassandra 4.1.x includes several security enhancements. Review the latest security features and best practices, such as enabling client-to-node encryption, node-to-node encryption, and advanced authentication mechanisms, to enhance the security posture of your Cassandra cluster.

Review and Update Backup Strategies

With the new version in place, reassess your backup strategies to ensure they are still effective and meet your recovery objectives. Verify that your backup and restore procedures are compatible with Cassandra 4.1.x and consider leveraging new tools or features that may have been introduced in this release for more efficient data management.

Artykuł Upgrading Apache Cassandra from Version 3.1.15 and Higher to 4.1.x on Ubuntu 20.04.5 LTS: A Comprehensive Guide pochodzi z serwisu soban.

Two machines with the following configuration will participate throughout the process:
up-page IP: 10.10.14.200
soban-pl IP: 10.10.11.105

So let’s move on to the frontend that distributes traffic to other machines.
The frontend is done by linux debian 11 (bullseye), in addition, I have the following entry in the repository (/etc/apt/sources.list):

#...
deb http://nginx.org/packages/debian/ bullseye nginx
deb-src http://nginx.org/packages/debian/ bullseye nginx

To install nginx, run the following commands:

# apt update
# apt install nginx

You should make sure that the traffic from the frontend has the appropriate port 80 transitions. You can read how to check the network transitions here: Check network connection and open TCP port via netcat.

The configuration of the frontend that distributes the traffic is as follows (/etc/nginx/conf.d/soban.pl.ssl.conf):

upstream soban-pl-webservers {
    server 10.10.11.105:80;
}

server {
    if ($host = www.soban.pl) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = soban.pl) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        server_name soban.pl www.soban.pl;
        return 301 https://soban.pl$request_uri;
}

server {
    listen 443 ssl http2;
    server_name  www.soban.pl;
    ssl_certificate /etc/letsencrypt/live/www.soban.pl/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.soban.pl/privkey.pem; # managed by Certbot
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    return 301 https://soban.pl$request_uri;
}

server {
    listen 443 ssl http2;
    server_name  soban.pl _;
    ssl_certificate /etc/letsencrypt/live/soban.pl/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/soban.pl/privkey.pem; # managed by Certbot
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
}

    location / {
        access_log /var/log/nginx/access-soban.pl.log;
        error_log /var/log/nginx/error-soban.pl.log;
        proxy_pass http://soban-pl-webservers;
        proxy_redirect https://soban-pl-webservers http://soban-pl-webservers;
        expires off;

        proxy_read_timeout       3500;
        proxy_connect_timeout    3250;

        proxy_set_header   X-Real-IP          $remote_addr;
        proxy_set_header   Host               $host;
        proxy_set_header   X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto  https;
        proxy_set_header   SSL_PROTOCOL $ssl_protocol;
        proxy_set_header   SSL_CLIENT_CERT $ssl_client_cert;
        proxy_set_header   SSL_CLIENT_VERIFY $ssl_client_verify;
        proxy_set_header   SSL_SERVER_S_DN $ssl_client_s_dn;

                proxy_set_header X-Scheme $scheme;
                proxy_ssl_session_reuse off;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
    }
      location ~ ^/(wp-admin|wp-login\.php) {
            auth_basic "Restricted";
            auth_basic_user_file /etc/nginx/conf.d/htpasswd;
           proxy_pass http://soban-pl-webservers;
           proxy_redirect https://soban-pl-webservers http://soban-pl-webservers;
           expires off;
           proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
           proxy_set_header        Host            $host;
           proxy_set_header        X-Real-IP       $remote_addr;
           proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      }

}

Configuration of the above-mentioned wordpress, additional authorization is also set when you try to log in to wp-admin, you can read about it here: More security wp-admin in nginx.

In the next step, check if the nginx configuration is correct by:

# service nginx configtest

If everything is fine, restart nginx:

# service nginx restart

In a virtual machine with nginx it should also be installed. This is the same as debian linux 11 (bullseye), so the respository should look like this:

#...
deb http://nginx.org/packages/debian/ bullseye nginx
deb-src http://nginx.org/packages/debian/ bullseye nginx

Just installing nginx looks the same as on a machine that acts as a proxy.

# apt update
# apt install nginx

All configuration is in /etc/nginx/conf.d/soban.pl.conf:

server {
    listen   80;

   client_max_body_size 20M;

    server_name soban.pl www.soban.pl;
    access_log /var/log/nginx/access-soban.pl.log; #access logi
    error_log /var/log/nginx/error-soban.log; # error logi
    port_in_redirect off;
    set_real_ip_from  10.10.11.105;
    real_ip_header    X-Forwarded-For;
    real_ip_recursive on;
       root /home/produkcja/wordpress/;
       index index.html index.php;

if ($host ~* ^www\.(.*))
{
    set $host_without_www $1;
    rewrite ^/(.*)$ $scheme://$host_without_www/$1 permanent;
}

    error_page 404 /index.php;


        location ~ \.php$ {
                root /home/produkcja/wordpress/; # dir where is wordpress
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php/php-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }
        location = /sitemap.xml {
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
                rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;
       }

location = /favicon.ico {
  return 204;
  access_log     off;
  log_not_found  off;
}

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
        }location ~* \.(pdf)$ {
expires 30d;
}

}

Also in this case, check the correctness of the nginx service configuration:

# service nginx configtest

Everything looks fine, so let’s move on to restarting the service:

# service nginx restart

If the whole configuration was done correctly, the page should be directed without encrypted traffic to the virtual machine with wordpress. A wordpress service with nginx is not the only one that can be hosted or proxied. We can direct traffic from nginx to e.g. jboss, apacha and all other web services. Of course, this requires a corresponding modification of the configuration presented above, but the general outline of the concept as an nginx proxy has been presented. You should also remember about the appropriate configuration of keys and certificates. In my case let’s encrypt works perfectly for this.

Artykuł Proxy through nginx frontend to the second virtual server wordpress pochodzi z serwisu soban.

As of this writing, the addressing is as follows:
new_machine IP: 10.10.14.100
old_machine IP: 10.10.14.101
Traffic will be routed on port 443 from new_machine to old_machine.

Before we go to proxy configuration, please make sure there are network transitions from new_machine (10.10.14.100) to old_machine (10.10.14.101) to port 443. You can read how to verify network connections here: check network connection and open tcp port via netcat.

We go to the installation of apache and mod_proxy:

# yum install httpd mod_proxy

After installing apache, go to the edition:

# vi /etc/httpd/conf.d/ssl.conf

Below are the news on the check level, what are the updates, and ip on the next service update:

<VirtualHost _default_:443>
SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:!RC4:!RC2:!DES:!3DES:!SHA:!SHA256:!SHA384:!MD5+HIGH:+MEDIUM:!KRB5
#…
<IfModule mod_proxy.c>
SSLProxyProtocol all
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyRequests On
    <Proxy *>
        Require all granted
    </Proxy>
    # backend server and forwarded path
    ProxyPass / https://10.10.14.101/
    ProxyPassReverse / https://10.10.14.101/
</IfModule>
</VirtualHost>

In order to verify the correctness of apache configuration, you can issue a command that will check it:

# service httpd configtest

If the apache configuration is correct, we can proceed to reloading apache:

# service httpd restart

At this point, we have a configured proxy connection. Before we move on to limiting traffic with iptables, I suggest you go to the site – with the new mod_proxy configured and test if everything is working properly and if there are any problems with the application.

Once everything is working fine, the network transitions are there, we can go to the iptables configuration for red hat 5. Let’s start by checking the system version:

# cat /etc/redhat-release

Now we are going to prepare iptables so that the network traffic is available on port 443 from the new_machine (10.10.14.100). To do this, edit the file /etc/sysconfig/iptables:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 443 -s 10.10.14.100 -j ACCEPT
-A INPUT -p tcp --dport 443 -j DROP
-A INPUT -p tcp --dport 80 -j DROP
-A INPUT -j ACCEPT
COMMIT

After iptables settings are correct, we can reload the service:

# /etc/init.d/iptables restart

In this way, we managed to cover up the weak encryption by proxying and diverting traffic to the new machine. This is not a recommended solution and you should try to transfer the application to a new environment compatible with the new system. However, in crisis situations, we can use this solution. Network traffic is not allowed by other IP addresses, so scanners will not be able to detect weak encryption on the old machine, and users using the old environment will not be able to use it. This does not change the fact that weak encryption is still set in the old environment and needs to be corrected. The example I gave is for the old red hat 5 and the new oracle linux 7, but it can be assumed that a similar solution and configuration is possible for other versions of the system.

Artykuł Improving encryption on old red hat 5 by new Oracle Linux 7 using apache mod_proxy pochodzi z serwisu soban.