Expanding Storage Space in Linux: Step-by-Step Guide using LVM and fdisk

Posted on by soban

Expanding disk space in Linux virtual machines is a key aspect of server system management. In this article, we show how to effectively increase disk space using LVM and fdisk tools, based on real system data.

Preliminary Preparations

Before making changes to partitions and volumes, it is important to check the current state of the disks in the system. We will use the lsblk command to identify available disks and partitions.

Here is an example of the lsblk command output on a machine:

Creating Snapshots

Before making changes to disk configurations, it is advisable to create a snapshot of the LVM volumes to ensure data can be restored in case of unexpected issues.

Modifying Partitions

Next, we proceed to modify the partitions using fdisk. We remove the existing partition and then create a new one that utilizes the entire available space on disk sdb.

Saving Changes

After properly configuring the partitions, we use the w command in fdisk to save the changes and update the partition table.

Executing pvscan

After modifying the partitions, we execute the pvscan command so the system can update information about available physical volumes.

Configuring LVM

After saving changes to the partition table, we need to update the LVM configuration to include the new disk space. We use the lvextend command with automatic file system resizing.

Summary

Expanding disk space on a Linux virtual machine enhances performance and the availability of storage space. Thanks to the steps described, managing disk space in systems using LVM becomes simpler and more efficient.

Troubleshooting Proxmox clusters and restoring the LXC container

Posted on by 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

and:

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

Expected output:

Then check the detailed cluster information with the following command:

Expected output:

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:

Output:

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

Restoring the Container

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

Output:

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.

Resolving performance_schema Issues in MySQL

Posted on by soban


During daily work with MySQL databases, specific challenges such as missing tables or errors related to the unrecognized database performance_schema can arise. These problems can significantly affect the performance and stability of database systems, and their diagnosis and resolution can often be complicated and time-consuming. To facilitate this task, I have created this guide, which is the result of my experiences and proven practices. I provide a comprehensive approach to identifying and fixing issues related to performance_schema. It’s quite simple to import the schema from a newly built database.

Of course, it’s best to perform a backup of the database before the entire operation.

Initial Diagnosis in MySQL

Start by identifying the problem in the MySQL shell:

Creating New Performance Schema in MySQL

Create a new performance schema from the MySQL command line:

Server Operations to Establish New MySQL Environment

Return to the system to configure a clean MySQL environment:

Then, start MySQL in safe mode to configure it – without external network interruptions:

Configuration and Verification in MySQL

Return to the MySQL command line to verify the configuration and configure the new database:

As you can see, here performance_schema is working correctly.
Update the root password in the MySQL environment to secure the new installation:

Restart MySQL in safe mode to ensure all configurations are applied:

Configure MySQL Server to Run New Database

After securing the new MySQL configuration, update the server configuration to use the new data directory:

Restart the MySQL service to load the my.cnf file during mysql startup:

Export and Restore Performance Schema in MySQL

With the new configuration, export performance_schema using MySQL commands and prepare for its restoration:

It’s necessary to shut down MySQL:

Restore the original MySQL data directory on the server, restart the MySQL service, and import the exported schema:

Make sure the default storage engine is running, e.g:

Don’t forget to remove the trash:

If you’ve reached this point, remember to delete the database backup – as long as everything is working. You did make one, right? 🙂

Setting Up Kerberos and CIFS Resource Mounting on Linux Systems

Posted on by soban

Ensure the following packages are installed to handle Kerberos authentication and mounting CIFS filesystems:

Kerberos Ticket Initialization

Initialize the Kerberos ticket with the following command:

To verify the ticket’s validity and see details, use:

Manual Resource Mounting

To manually mount a CIFS resource, use the command below. Replace yourserver/yourresource and /your/mountpoint with the appropriate server address and local mount point:

Auto-mounting via fstab

For persistent configuration that survives reboots, add the following entry to your /etc/fstab:

Summary

These settings are crucial for ensuring secure and reliable access to network resources using Kerberos on Linux systems. Always ensure your Kerberos tickets are valid and renew them as necessary. For any issues related to mounting or authentication, refer to the system logs or consult your system administrator.

How to prevent hibernation and sleep on debian and proxmox laptops when the lid is closed

Posted on by 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):

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.

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:

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.

Extending SWAP space on Proxmox using lvreduce

Posted on by 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

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.

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

Step 3: Using lvreduce

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

Step 4: Deactivating SWAP

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

Step 5: Expanding SWAP

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

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.

MySQL Troubleshooting – ErrorCode: 1114

Posted on by soban


Introduction

Working with MySQL, you may encounter various errors that can disrupt system operations. Error code 1114 is one of them and indicates a situation where the table the user is trying to write data to is full. This issue is particularly significant in the MySQL replication system, where its resolution is crucial for ensuring work continuity.

Problem Description

Error 1114 manifests itself with the message: “Could not execute Write_rows event on table docs; The table ‘docs’ is full”. This means that new rows cannot be written due to exceeding the size of the temporary table. The detailed error message might look like this:

Login to MySQL:

Change variable values:

After making these changes, all new connections to the MySQL server will use these updated values. You can verify them by performing:

Or

Now replication can be resumed and should work better. However, remember to modify the configuration so that after restarting MySQL these variables are set correctly. It may be necessary here to resume replication (if it was previously stopped):

If the problem has been resolved, at this stage checking the replication status:

Should not return any errors.

Modify the configuration file /etc/mysql/my.cnf:

Restart MySQL service:

Before restarting the service, it is recommended to execute SHUTDOWN; in the MySQL client.
Remember to resume replication.

Important Notes

  • System Resources: Ensure the server has sufficient RAM to handle the increased variable values.
  • Performance Monitoring: After making the changes, monitor performance to verify that the problem has been resolved.
  • Configuration Durability: Changes to the configuration file should be permanent to avoid resetting values after a restart.

Additional Verification Steps

  • Check Available Disk Space: The problem might also stem from lack of available disk space. This can be verified using the following command:

Summary

Resolving the issue associated with error code 1114 in MySQL replication requires understanding and adjusting the system configuration. The described steps show how increasing the size of the temporary table can prevent this error, enabling smooth operation of the replication system.

Automating the Backup Process in Proxmox: Practical Crontab Script and Configuration

Posted on by soban

In today’s world, where data is becoming increasingly valuable, proper backup management is crucial for the security of information systems. In this article, I present an effective way to automate the backup of key configuration files in Proxmox-based systems using a simple bash script and Crontab configuration.

Bash Script for Backup of the /etc Directory

The /etc file contains critical system configuration files that are essential for the proper functioning of the operating system and various applications. Loss or damage to these files can lead to serious problems. Below, I present an effective script, backup-etc.sh, that allows for the automated backup of this directory:

This script performs the following operations:

  1. Generates the current date and time, which are added to the name of the archive to easily identify individual copies.
  2. Uses the tar program with zstd compression to create an archived and compressed copy of the /etc directory.
  3. Removes archives older than 100 days from the /var/lib/vz/dump/ location, thus ensuring optimal disk space management.

Adding Script to Crontab

To automate the backup process, the script should be added to crontab. Below is a sample configuration that runs the script daily at 2:40 AM:

Redirecting output to /dev/null ensures that operations are performed quietly without generating additional output to standard output.

Download the Script from soban.pl

The backup-etc.sh script is also available for download from the soban.pl website. You can download it using the following wget command and immediately save it as /root/backup-etc.sh:

With this simple command, the script is downloaded from the server and granted appropriate executable permissions.

Benefits and Modifications

The backup-etc.sh script is flexible and can be easily modified to suit different systems. It is default placed in the /var/lib/vz/dump/ folder, which is a standard backup storage location in Proxmox environments. This simplifies backup management and can be easily integrated with existing backup solutions.

By keeping backups for 100 days, we ensure a balance between availability and disk space management. Old copies are automatically deleted, minimizing the risk of disk overflow and reducing data storage costs.

Summary

Automating backups using a bash script and Crontab is an effective method to secure critical system data. The backup-etc.sh script provides simplicity, flexibility, and efficiency, making it an excellent solution for Proxmox system administrators. I encourage you to adapt and modify this script according to your own needs to provide even better protection for your IT environment.

Upgrading Apache Cassandra from Version 3.1.15 and Higher to 4.1.x on Ubuntu 20.04.5 LTS: A Comprehensive Guide

Posted on by 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:

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:

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:

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.

Stop the Cassandra Service:

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

Upgrading Cassandra

Update Source List:

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

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):

Modify Configuration:

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

Update JAMM Library:

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

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.

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:

Restart the Cassandra Service:

Apply the new version by restarting the Cassandra service:

Verify Upgrade:

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

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.):

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.

Simplified Proxmox VE 8 Installation on Debian 12 Bookworm

Posted on by soban

Proxmox VE is a comprehensive, open-source server management platform that seamlessly integrates KVM hypervisor and LXC containers. Today, we present a streamlined process for installing Proxmox VE 8 on Debian 12 Bookworm, based on the official guidance from the Proxmox VE Installation Guide.

Prerequisites

  • A fresh Debian 12 Bookworm installation.
  • A user with sudo privileges.
  • Internet connectivity.

Installation Scripts

We’ve divided the installation into two scripts. The first script prepares your system and installs the Proxmox VE kernel. The second script continues the process after a system reboot, installing the remaining Proxmox VE packages.

Remember, all these commands need to be executed from the root user level, so:

First Part: System Preparation and Kernel Installation

Start by downloading the first script which prepares your system and installs the Proxmox VE kernel:

Run the script with the following command:

Here is the content of the script:

After running the first script, your system will reboot. At this stage, you may encounter a few dialogs from the system, which are part of the normal package configuration steps. For this simplified installation, you can accept the default options by pressing Enter.

Screenshots during Installation

The selection of GRUB installation configuration.

GRUB Configuration – A new version of the GRUB bootloader configuration file is available. It’s recommended to keep the local version currently installed unless you are aware of the changes. As with the previous dialogs, pressing Enter will select the default action.

The selection of postfix installation configuration.

Postfix Configuration – This dialog appears when installing the postfix package, which is a mail transport agent. The default option “Internet Site” is suitable for most cases. Pressing Enter accepts this configuration.

Setting the system mail name.

System Mail Name – Here you specify the FQDN (Fully Qualified Domain Name) for the system mail. The default value is usually adequate unless you have a specific domain name for your server. Again, pressing Enter will continue with the default configuration.

There might be issues encountered towards the end of the first script installation, such as:

However, the second part of the script, executed after the reboot, addresses these problems.
After a successful reboot of the machine, log into the system and proceed to the second script.

Second Part: Completing Proxmox VE Installation

After your system has rebooted, proceed with downloading the second script:

Execute the second part of the installation with the command:

This is the content of the second script:

Once the second script completes, you will be able to access the Proxmox VE web interface using the URL displayed at the script’s conclusion. Log in with the ‘root’ username and your root password.

Upon loading the page, you may encounter a certificate trust error – this is normal at this stage, and you can safely accept that it is unsafe and proceed to access the page for managing Proxmox. If you don’t know the root password, you can reset it by executing ‘passwd‘ as root. Good luck!