soban - Strona 2 z 3 - IT, Linux, Servers, Security

Ulepszanie zarządzania maszynami wirtualnymi za pomocą agenta gościa QEMU na Proxmox

Posted on 11 lutego, 202511 lutego, 2025 by soban

Zastanawiałeś się kiedyś, jak usprawnić zarządzanie i monitorowanie maszyn wirtualnych w swoim środowisku Proxmox? QEMU Guest Agent to prawdziwy przełom, oferujący narzędzia, które znacząco ułatwiają interakcję z wirtualnymi systemami. Przyjrzyjmy się, jak to narzędzie może zmienić twoje podejście.

Dlaczego QEMU Guest Agent jest niezbędny?

Synchronizacja czasu: Utrzymanie spójnego czasu pomiędzy maszynami wirtualnymi a hostem może być trudne, ale QEMU Guest Agent automatyzuje to, zapewniając płynne działanie operacji zależnych od czasu.
Zarządzanie zasilaniem: Wyobraź sobie możliwość wyłączania lub restartowania maszyn wirtualnych bezpośrednio z panelu Proxmox — nie ma potrzeby logowania się do każdej VM. To nie tylko wygodne, ale także oszczędza czas.
Monitorowanie systemu: Uzyskaj szczegółowe informacje o systemach plików, aktywności sieciowej i innych parametrach operacyjnych bezpośrednio z hosta. Ten poziom monitorowania pozwala na terminową diagnostykę i regulacje.
Zarządzanie dyskami: Obsługa operacji na dyskach bez konieczności bezpośredniej interwencji na VM ułatwia tworzenie kopii zapasowych i przywracanie danych jak nigdy dotąd.

Konfiguracja QEMU Guest Agent na twoim serwerze Proxmox

Uruchomienie QEMU Guest Agent obejmuje kilka prostych kroków:

Aktywacja Agenta: Zaloguj się do panelu Proxmox, przejdź do sekcji 'Opcje’ wybranej maszyny wirtualnej i upewnij się, że opcja 'QEMU Guest Agent’ jest zaznaczona.

Następnie instalacja na maszynie wirtualnej Ubuntu:

sudo apt-get install qemu-guest-agent
sudo systemctl start qemu-guest-agent
sudo systemctl enable qemu-guest-agent

sudo apt-get install qemu-guest-agent

sudo systemctl start qemu-guest-agent

sudo systemctl enable qemu-guest-agent

W celu sprawdzenia, czy odpowiednio działa qeumu-guest-agent możesz wykonać polecenie:

systemctl status qemu-guest-agent

1	systemctl status qemu-guest-agent

QEMU Guest Agent nie tylko ułatwia życie, automatyzując rutynowe zadania — również zwiększa bezpieczeństwo i efektywność twojego wirtualnego środowiska. Niezależnie od tego, czy zarządzasz pojedynczą maszyną wirtualną czy całym zbiorem, jest to nieocenione narzędzie w twoim arsenale.

Automatyczne usuwanie najstarszych plików na zdalnym dysku QNAP przez SSHFS

Posted on 7 lutego, 202511 lutego, 2025 by soban

Automatyzacja Zarządzania Przestrzenią Dyskową w Środowisku Linux

W dzisiejszym cyfrowym świecie, gdzie dane gromadzone są w coraz większych ilościach, zarządzanie przestrzenią dyskową staje się kluczowym elementem utrzymania efektywności operacyjnej systemów. W tym artykule przedstawię skrypt, który automatyzuje proces zarządzania przestrzenią na zdalnym dysku montowanym przez SSHFS, szczególnie przydatny dla administratorów systemów, którzy regularnie muszą radzić sobie z zapełniającymi się nośnikami danych.

Wymagania wstępne

Przed rozpoczęciem, upewnij się, że na twoim systemie zainstalowane jest SSHFS oraz wszystkie niezbędne pakiety umożliwiające jego prawidłową pracę. SSHFS pozwala na montowanie systemów plików zdalnych przez SSH, co jest kluczowe dla działania naszego skryptu. Aby zainstalować SSHFS oraz niezbędne narzędzia, w tym pakiet umożliwiający przekazywanie hasła (sshpass), użyj poniższego polecenia:

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

1 2	sudo apt-get update sudo apt-get install sshfs fuse sshpass -y

Skrypt Bash do zarządzania przestrzenią dyskową

Nasz skrypt Bash skupia się na monitorowaniu i utrzymaniu określonego procentu wolnej przestrzeni dyskowej na zdalnym dysku, montowanym za pomocą SSHFS. Oto główne funkcje skryptu:

Definicja Celów:

TARGET_USAGE=70 – procent przestrzeni dyskowej, który chcemy utrzymać jako zajęty. Skrypt będzie działał na rzecz utrzymania przynajmniej 30% wolnego miejsca na dysku.

Punkt Montowania i Ścieżki:

MOUNT_POINT=”/mnt/qnapskorupki” – lokalny katalog, w którym montowany jest zdalny dysk. TARGET_DIRS=”$MOUNT_POINT/up*.soban.pl” – ścieżki katalogów, w których skrypt będzie szukał plików do usunięcia, jeśli zajdzie taka potrzeba.

Funkcja check_qnap: Ta funkcja sprawdza, czy dysk jest zamontowany i czy katalog montowania nie jest pusty. Jeśli są problemy, skrypt próbuje odmontować i ponownie zamontować dysk, używając sshfs z hasłem przekazanym przez sshpass.

Usuwanie Plików: Skrypt monitoruje użycie dysku i, jeśli przekroczone jest TARGET_USAGE, znajduje i usuwa najstarsze pliki w określonych katalogach aż do osiągnięcia docelowego poziomu wolnej przestrzeni.

#!/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."

#!/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

# 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

}

# 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

# 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."

Przykładowe wywołanie skryptu:

skrypt zaczyna pracę i stopniowo usuwa pliki

skrypt będzie pracować aż do osiągnięcia 70% zgodnie z założeniem:

Pobieranie skryptu i dodawanie do crontaba

Skrypt oczywiście należy dostosować pod swoje wymagania, jednak jeśli chcesz go pobrać i dodać do crontaba to:

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

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

Jeśli chcemy zautomatyzować proces usuwania np pod koniec dnia, to warto dodać do crontaba następujący wpis:

crontab -e

1	crontab -e

Skrypt będzie się uruchamiać w tym przypadku o 23:55 każdego dnia:

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

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

Należy zachować powyżej odpowiednią ścieżkę do skryptu.

Bezpieczeństwo i optymalizacja

Skrypt używa hasła wprost w linii komend, co może stanowić ryzyko bezpieczeństwa. W praktycznym zastosowaniu zaleca się użycie bardziej zaawansowanych metod autentykacji, na przykład kluczy SSH, które są bezpieczniejsze i nie wymagają jawnej obecności hasła w skrypcie. Jednak w przypadku QNAPa posłużyliśmy się hasłem pisząc ten skrypt.

Podsumowanie

Prezentowany skrypt jest przykładem, jak można automatyzować codzienne zadania administracyjne, takie jak zarządzanie przestrzenią dyskową, zwiększając tym samym efektywność i niezawodność operacji. Jego implementacja w realnych środowiskach IT może znacznie usprawnić procesy zarządzania danymi, zwłaszcza w sytuacjach, gdzie szybkie reagowanie na zmiany w użyciu dysku jest krytyczne.

Jak automatycznie wyłączyć laptopa przy niskim stanie baterii w systemie Linux

Posted on 24 stycznia, 202524 stycznia, 2025 by soban

Automatyczne wyłączanie laptopa przy niskim stanie baterii

Zachowanie długiej żywotności baterii i ochrona danych są kluczowe dla użytkowników laptopów. W tym artykule pokażemy, jak stworzyć prosty skrypt Bash, który automatycznie wyłączy Twój laptop, gdy poziom naładowania baterii spadnie poniżej 20%. Dodatkowo, dowiesz się, jak ustawić crontab, aby skrypt był uruchamiany co 10 minut, zapewniając ciągłe monitorowanie.

Tworzenie skryptu Bash

Skrypt Bash, który przygotowaliśmy, będzie sprawdzać aktualny poziom naładowania baterii i porównywać go z ustalonym minimalnym progiem. Jeśli poziom baterii spadnie poniżej tego progu, skrypt inicjuje wyłączenie systemu, co pomaga w ochronie danych i sprzętu.

#!/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

#!/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."

Możesz też pobrać skrypt:

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

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

Nie zapomnij o nadaniu uprawnień do uruchamiania go:

chmod +x check_battery.sh

1	chmod +x check_battery.sh

Konfiguracja Crontab

Crontab to narzędzie, które pozwala na planowanie zadań w systemie Linux. Dzięki niemu możemy ustawić regularne sprawdzanie stanu baterii.

crontab -e
# Add the following line to crontab to run the script every 10 minutes
*/10 * * * * /root/check_battery.sh >> /path/to/log_battery.txt 2>&1

crontab -e

# Add the following line to crontab to run the script every 10 minutes

*/10 * * * * /root/check_battery.sh >> /path/to/log_battery.txt 2>&1

Podsumowanie

Dzięki temu rozwiązaniu, możesz być spokojny o stan swojego laptopa nawet podczas intensywnego użytkowania. Automatyczne wyłączanie przy niskim stanie baterii nie tylko chroni sprzęt, ale także pomaga w utrzymaniu dłuższej żywotności baterii.

Rozszerzanie Przestrzeni Dyskowej w Linux: Przewodnik Krok po Kroku z Użyciem LVM i fdisk

Posted on 13 listopada, 202413 listopada, 2024 by soban

Poszerzanie przestrzeni dyskowej w wirtualnych maszynach Linux to kluczowy element zarządzania systemami serwerowymi. W tym artykule pokazujemy, jak efektywnie zwiększyć przestrzeń dyskową używając narzędzi LVM i fdisk, bazując na rzeczywistych danych z systemu.

Wstępne przygotowania

Przed przystąpieniem do zmian w partycjach i woluminach, ważne jest, aby sprawdzić aktualny stan dysków w systemie. Użyjemy polecenia lsblk, aby zidentyfikować dostępne dyski i partycje.

lsblk

lsblk

Oto przykład wyniku polecenia lsblk na maszynie:

NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0                       7:0    0 55.7M  1 loop /snap/core18/2829
sda                         8:0    0   42G  0 disk
├─sda1                      8:1    0  512M  0 part /boot/efi
├─sda2                      8:2    0    1G  0 part /boot
└─sda3                      8:3    0 40.5G  0 part
└─ubuntu--vg-ubuntu--lv 253:0    0 78.5G  0 lvm  /
sdb                         8:16   0  350G  0 disk
└─sdb1                      8:17   0   60G  0 part
└─ubuntu--vg-ubuntu--lv 253:0    0 78.5G  0 lvm  /
sr0                        11:0    1 1024M  0 rom

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

loop0 7:0 0 55.7M 1 loop /snap/core18/2829

sda 8:0 0 42G 0 disk

├─sda1 8:1 0 512M 0 part /boot/efi

├─sda2 8:2 0 1G 0 part /boot

└─sda3 8:3 0 40.5G 0 part

└─ubuntu--vg-ubuntu--lv 253:0 0 78.5G 0 lvm /

sdb 8:16 0 350G 0 disk

└─sdb1 8:17 0 60G 0 part

└─ubuntu--vg-ubuntu--lv 253:0 0 78.5G 0 lvm /

sr0 11:0 1 1024M 0 rom

Tworzenie snapshotów

Zanim przystąpimy do zmian w konfiguracji dysków, zaleca się wykonanie snapshotu woluminów LVM, aby zapewnić możliwość przywrócenia danych w przypadku nieoczekiwanych problemów.

lvcreate -L 20G -s -n my_snapshot /dev/ubuntu-vg/ubuntu-lv

1	lvcreate -L 20G -s -n my_snapshot /dev/ubuntu-vg/ubuntu-lv

Modyfikacja partycji

Następnie, przystępujemy do modyfikacji partycji, korzystając z fdisk. Usuwamy istniejącą partycję, a potem tworzymy nową, która wykorzysta całą dostępną przestrzeń na dysku sdb.

fdisk /dev/sdb

1	fdisk /dev/sdb

Zapis zmian

Po prawidłowym skonfigurowaniu partycji, korzystamy z komendy w w fdisk, aby zapisać zmiany i zaktualizować tabelę partycji.

Command (m for help): w

1	Command (m for help): w

Wykonanie pvscan

Po modyfikacji partycji, wykonujemy polecenie pvscan, aby system mógł zaktualizować informacje o dostępnych fizycznych woluminach.

pvscan

pvscan

Konfiguracja LVM

Po zapisaniu zmian w tabeli partycji, musimy zaktualizować konfigurację LVM, aby uwzględnić nową przestrzeń dyskową. Używamy polecenia lvextend z automatycznym rozszerzaniem systemu plików.

lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv -r

1	lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv -r

Podsumowanie

Rozszerzenie przestrzeni dyskowej na wirtualnej maszynie Linux poprawia wydajność i dostępność przestrzeni do przechowywania danych. Dzięki opisanym krokom, zarządzanie przestrzenią dyskową w systemach wykorzystujących LVM staje się prostsze i bardziej efektywne.

Rozwiązywanie problemów z klastrami Proxmox i przywracanie kontenera LXC

Posted on 13 listopada, 202413 listopada, 2024 by soban

Podczas zarządzania klastrami Proxmox można napotkać różne trudności techniczne, takie jak niespójności w konfiguracji klastra lub problemy z przywracaniem kontenerów LXC. Znalezienie i rozwiązanie tych problemów jest kluczowe dla utrzymania stabilności i wydajności środowiska wirtualizacji. W tym artykule przedstawiam szczegółowy przewodnik, jak zdiagnozować i rozwiązać problem z nieosiągalnym węzłem oraz jak pomyślnie przywrócić kontener LXC.

Zanim przystąpisz do jakichkolwiek działań, upewnij się, że masz aktualny backup systemu.

Diagnostyka stanu klastra Proxmox

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

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

oraz:

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'

1 2	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'

Aby zrozumieć stan klastra, wykonaj na węźle node-up-page-04 polecenie:

pvecm nodes

1	pvecm nodes

Oczekiwany output:

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

Membership information

----------------------

Nodeid Votes Name

1 1 node-up-page-01

2 1 node-up-page-04 (local)

Następnie sprawdź szczegółowe informacje o klastrze za pomocą polecenia:

pvecm status

1	pvecm status

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

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)

Usuwanie pliku konfiguracyjnego kontenera i czyszczenie danych

Odkryłem, że plik konfiguracyjny kontenera 107 wciąż istnieje na systemie plików klastra w ścieżce:

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

1	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

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

Aby usunąć ten plik i wszelkie pozostałości danych związanych z odłączonym węzłem, wykonaj:

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

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

Przywracanie kontenera

Po usunięciu pliku konfiguracyjnego, przywróciłem kontener LXC na węźle node-up-page-04 za pomocą polecenia:

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

1	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'

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'

Proces przywracania zakończył się pomyślnie, a kontener był gotowy do użycia. Ten przypadek pokazuje, jak ważna jest dokładna diagnostyka i zarządzanie plikami konfiguracyjnymi w Proxmox podczas pracy z klastrami. Warto prowadzić regularne przeglądy konfiguracji, aby unikać niespójności i problemów operacyjnych w przyszłości.

Rozwiązywanie problemów związanych z performance_schema w MySQL

Posted on 7 listopada, 20247 listopada, 2024 by soban

Podczas codziennej pracy z bazami danych MySQL, mogą pojawić się specyficzne wyzwania, takie jak brakujące tabele lub błędy związane z nierozpoznaną bazą danych performance_schema. Te problemy mogą znacząco wpływać na wydajność i stabilność systemów bazodanowych, a ich diagnozowanie i rozwiązywanie bywa często skomplikowane i czasochłonne. Aby ułatwić to zadanie, stworzyłem ten przewodnik, który jest wynikiem moich doświadczeń oraz sprawdzonych praktyk. Zapewniam kompleksowe podejście do identyfikacji i naprawy problemów związanych z performance_schema. Jest to dosyć proste zaimportowanie schematu z nowo zbudowanej bazy danych.

Oczywiście przed całą operacją należy wykonać backup bazy najlepiej.

Początkowa diagnoza w MySQL

Zacznij od zidentyfikowania problemu w powłoce MySQL:

SHOW VARIABLES LIKE 'default_storage_engine';
ERROR 1146 (42S02): Table 'performance_schema.session_variables' doesn't exist
USE performance_schema;
ERROR 1049 (42000): Unknown database 'performance_schema';

SHOW VARIABLES LIKE 'default_storage_engine';

ERROR 1146 (42S02): Table 'performance_schema.session_variables' doesn't exist

USE performance_schema;

ERROR 1049 (42000): Unknown database 'performance_schema';

Utworzenie nowego schematu Performance Schema w MySQL

Tworzenie nowego schematu performance schema z linii komend MySQL:

CREATE DATABASE performance_schema;
shutdown;
\q

CREATE DATABASE performance_schema;

shutdown;

Operacje serwerowe do ustanowienia nowego środowiska MySQL

Wracamy do systemu, aby skonfigurować czyste środowisko MySQL:

systemctl stop mysql.service
mkdir /var/lib/mysql_new
mysqld --initialize --user=mysql --basedir=/usr --datadir=/var/lib/mysql_new
chown -R mysql:mysql /var/lib/mysql_new
cd /var/lib/mysql_new

systemctl stop mysql.service

mkdir /var/lib/mysql_new

mysqld --initialize --user=mysql --basedir=/usr --datadir=/var/lib/mysql_new

chown -R mysql:mysql /var/lib/mysql_new

cd /var/lib/mysql_new

Następnie, uruchom MySQL w trybie bezpiecznym, aby skonfigurować go – bez zewnętrznych przerwań sieciowych:

sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-grant-tables --skip-networking

1	sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-grant-tables --skip-networking

Konfiguracja i weryfikacja w MySQL

Powróć do linii komend MySQL, aby zweryfikować konfigurację i skonfigurować nową bazę danych:

mysql -u root
SHOW DATABASES;
USE performance_schema;
SHOW TABLES;

mysql -u root

SHOW DATABASES;

USE performance_schema;

SHOW TABLES;

Jak widać, tutaj performance_schema działa poprawnie.
Zaktualizuj hasło roota w środowisku MySQL, aby zabezpieczyć nową instalację:

USE mysql;
UPDATE user SET authentication_string=PASSWORD('NewSecurePassword');
FLUSH PRIVILEGES;
shutdown;
\q

USE mysql;

UPDATE user SET authentication_string=PASSWORD('NewSecurePassword');

FLUSH PRIVILEGES;

shutdown;

Uruchom ponownie MySQL w trybie bezpiecznym, aby upewnić się, że wszystkie konfiguracje zostały zastosowane:

sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-networking

1	sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-networking

Konfiguracji MySQL na serwerze w celu uruchomienia nowej bazy danych

Po zabezpieczeniu nowej konfiguracji MySQL, zaktualizuj konfigurację serwera, aby używać nowego katalogu danych:

vi /etc/mysql/my.cnf
# Zmień datadir na:
datadir=/var/lib/mysql_new

vi /etc/mysql/my.cnf

# Zmień datadir na:

datadir=/var/lib/mysql_new

Uruchom ponownie usługę MySQL, aby plik my.cnf został wczytany podczas startowania mysqla:

systemctl start mysql.service

1	systemctl start mysql.service

Eksportuj i przywróć schemat Performance Schema w MySQL

Z nową konfiguracją, eksportuj performance_schema za pomocą poleceń MySQL i przygotuj się do jego przywrócenia:

mysqldump -u root -p --no-data --skip-lock-tables performance_schema > /root/performance_schema.sql

1	mysqldump -u root -p --no-data --skip-lock-tables performance_schema > /root/performance_schema.sql

Należy wyłączyć mysqla:

shutdown;
\q

1 2	shutdown; \q

Przywróć oryginalny katalog danych MySQL na serwerze, uruchom ponownie usługę MySQL i zaimportuj wyeksportowany schemat:

vi /etc/mysql/my.cnf
# Zmień datadir z powrotem na:
datadir=/var/lib/mysql_old
systemctl start mysql.service
mysql -u root -p performance_schema < /root/performance_schema.sql
systemctl restart mysql.service

vi /etc/mysql/my.cnf

# Zmień datadir z powrotem na:

datadir=/var/lib/mysql_old

systemctl start mysql.service

mysql -u root -p performance_schema < /root/performance_schema.sql

systemctl restart mysql.service

Upewnij się, że domyślny silnik przechowywania działa, np:

SHOW VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+
1 row in set (0.00 sec)

SHOW VARIABLES LIKE 'default_storage_engine';

+------------------------+--------+

| Variable_name | Value |

+------------------------+--------+

| default_storage_engine | InnoDB |

+------------------------+--------+

1 row in set (0.00 sec)

Nie zapomnij usunąć śmieci:

rm -rf /var/lib/mysql_new/ /root/performance_schema.sql

1	rm -rf /var/lib/mysql_new/ /root/performance_schema.sql

Jeśli dotarłeś tutaj, pamiętaj o usunięciu backupu bazy danych – o ile wszystko działa. Bo wykonałeś takowy? 🙂

Konfiguracja Kerberosa i montowanie zasobów CIFS w systemach Linux

Posted on 31 maja, 20245 czerwca, 2024 by soban

Upewnij się, że na twoich systemach zainstalowane są następujące pakiety, które są niezbędne do obsługi uwierzytelniania Kerberos oraz montowania systemów plików CIFS:

apt install krb5-user cifs-utils keyutils

1	apt install krb5-user cifs-utils keyutils

Inicjalizacja biletu Kerberos

Zainicjuj bilet Kerberos za pomocą poniższego polecenia:

kinit twojanazwa@twojadomena.com

1	kinit twojanazwa@twojadomena.com

Aby zweryfikować ważność biletu i zobaczyć szczegóły, użyj:

klist

klist

Ręczne montowanie zasobów

Aby ręcznie zamontować zasób CIFS, użyj poniższego polecenia. Zamień twójserwer/twójzasób oraz /twójpunktmonowania na odpowiedni adres serwera i lokalny punkt montowania:

mount -t cifs //twójserwer/twójzasób /twójpunktmonowania -o sec=krb5,cruid=0,uid=0,gid=0,vers=3.1.1,noperm,dir_mode=0777,file_mode=0777,iocharset=utf8

1	mount -t cifs //twójserwer/twójzasób /twójpunktmonowania -o sec=krb5,cruid=0,uid=0,gid=0,vers=3.1.1,noperm,dir_mode=0777,file_mode=0777,iocharset=utf8

Automatyczne montowanie przez fstab

Dla trwałej konfiguracji, która przetrwa restarty, dodaj poniższy wpis do swojego pliku /etc/fstab:

//twójserwer/twójzasób /twójpunktmonowania cifs sec=krb5,cruid=0,uid=0,gid=0,vers=3.1.1,noperm,dir_mode=0777,file_mode=0777,iocharset=utf8,_netdev,x-systemd.automount,x-systemd.requires=network-online.target 0 0

1	//twójserwer/twójzasób /twójpunktmonowania cifs sec=krb5,cruid=0,uid=0,gid=0,vers=3.1.1,noperm,dir_mode=0777,file_mode=0777,iocharset=utf8,_netdev,x-systemd.automount,x-systemd.requires=network-online.target 0 0

Podsumowanie

Te ustawienia są kluczowe, aby zapewnić bezpieczny i niezawodny dostęp do zasobów sieciowych przy użyciu Kerberosa w systemach Linux. Zawsze upewnij się, że twoje bilety Kerberos są ważne i odnawiaj je w miarę potrzeby. W przypadku problemów związanych z montowaniem lub uwierzytelnianiem, odwołaj się do dzienników systemowych lub skonsultuj się z administratorem systemu.

Jak zapobiegać hibernacji i uśpieniu na laptopach z debianem i proxmox podczas zamknięcia pokrywy

Posted on 19 kwietnia, 202419 kwietnia, 2024 by soban

Serwery wirtualizacyjne bazujące na systemach z rodziny Debian, takie jak Proxmox, są często używane w środowiskach testowych, gdzie ciągła dostępność jest kluczowa. Czasami te serwery są instalowane na laptopach, które są wykorzystywane jako niskobudżetowe lub przenośne rozwiązania. Standardowe ustawienia zarządzania energią w laptopach mogą jednak prowadzić do niepożądanych zachowań, takich jak uśpienie lub hibernacja przy zamknięciu pokrywy. Poniżej opisuję, jak zmienić te ustawienia w systemie operacyjnym bazującym na Debianie, aby zapewnić nieprzerwaną pracę serwera.

Krok 1: Dostęp do pliku konfiguracyjnego

Otwórz terminal i wpisz poniższe polecenie, aby edytować plik /etc/systemd/logind.conf przy użyciu edytora tekstowego (np. nano):

nano /etc/systemd/logind.conf

1	nano /etc/systemd/logind.conf

Krok 2: Modyfikacja ustawień logind

Znajdź linijkę zawierającą HandleLidSwitch i zmień jej wartość na ignore. Jeśli linia jest zakomentowana (poprzedzona znakiem #), usuń znak #. Możesz również dodać tę linię na końcu pliku, jeśli nie istnieje.

HandleLidSwitch=ignore

1	HandleLidSwitch=ignore

Krok 3: Zastosowanie i restart usługi

Po wprowadzeniu zmian i zapisaniu pliku, należy zrestartować usługę systemd-logind, aby zmiany weszły w życie. Użyj poniższego polecenia w terminalu:

systemctl restart systemd-logind

1	systemctl restart systemd-logind

Dzięki tym zmianom, zamknięcie pokrywy laptopa nie będzie już inicjować hibernacji ani uśpienia, co jest szczególnie ważne w przypadku korzystania z serwerów bazujących na Debianie, w tym Proxmox, jako rozwiązania serwerowe.

Rozszerzanie przestrzeni SWAP na Proxmoxie przy użyciu lvreduce

Posted on 18 kwietnia, 202418 kwietnia, 2024 by soban

Wprowadzenie

Zarządzanie pamięcią SWAP jest kluczowym elementem administrowania systemami operacyjnymi Linux, szczególnie w środowiskach wirtualizacji takich jak Proxmox. SWAP służy jako „pamięć wirtualna”, która może być używana, gdy fizyczna pamięć RAM systemu jest zapełniona. W tym artykule pokażemy, jak zwiększyć przestrzeń SWAP na serwerze Proxmox, korzystając z narzędzia lvresize do zwolnienia miejsca na dysku, które można następnie przeznaczyć na SWAP.

Przegląd problemu

Użytkownik chce zwiększyć przestrzeń SWAP z 8 GB do 16 GB, ale napotyka problem braku dostępnej przestrzeni w grupie woluminów LVM, która jest wymagana do zwiększenia SWAP.

Krok 1: Sprawdzenie dostępnej przestrzeni

vgs

vgs

To polecenie wyświetla grupy woluminów wraz z ich rozmiarami i dostępną przestrzenią.

Krok 2: Zmniejszenie wolumenu

Załóżmy, że istnieje wolumen root o rozmiarze 457.26 GB, który można zmniejszyć, aby uzyskać dodatkowe 8 GB na SWAP. Przed zmniejszeniem wolumenu konieczne jest zmniejszenie systemu plików na tym wolumenie.

resize2fs /dev/pve/root 449.26G

1	resize2fs /dev/pve/root 449.26G

Jednakże w przypadku systemu plików XFS, zmniejszenie musi nastąpić w trybie offline lub z live CD.

Krok 3: Użycie lvreduce

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

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

To polecenie zmniejszy wolumen root o 8 GB, co potwierdza się komunikatem o zmianie rozmiaru wolumenu.

Krok 4: Deaktywacja SWAP

swapoff -a

1	swapoff -a

Przed rozpoczęciem zmian w rozmiarze SWAP, należy najpierw wyłączyć SWAP za pomocą powyższego polecenia.

Krok 5: Rozszerzenie SWAP

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

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

mkswap /dev/pve/swap

swapon /dev/pve/swap

Powyższe polecenia najpierw zwiększają przestrzeń SWAP, następnie formatują ją i aktywują ponownie.

swapon --show

1	swapon --show

Na koniec, weryfikujemy aktywne obszary SWAP używając polecenia powyżej, aby upewnić się, że wszystko zostało poprawnie skonfigurowane.

Proces ten pokazuje, jak można elastycznie zarządzać przestrzenią dyskową na serwerach Proxmox, dostosowując rozmiar SWAP w zależności od potrzeb. Użycie lvreduce wymaga ostrożności, gdyż każde działanie na partycjach i woluminach niesie ryzyko utraty danych, dlatego zawsze zalecane jest wykonanie kopii zapasowych przed przystąpieniem do zmian.

Rozwiązywanie Problemu MySQL – Error_code: 1114

Posted on 17 kwietnia, 202417 kwietnia, 2024 by soban

Wprowadzenie

Pracując z MySQL, można napotkać różne błędy, które mogą zakłócić działanie systemu. Kod błędu 1114 jest jednym z nich i wskazuje na sytuację, gdy tabela, do której użytkownik próbuje zapisać dane, jest pełna. Ten problem jest szczególnie znaczący w systemie replikacji MySQL, gdzie jego rozwiązanie jest kluczowe dla zapewnienia ciągłości pracy.

Opis problemu

Błąd 1114 manifestuje się komunikatem: „Could not execute Write_rows event on table docs; The table 'docs’ is full”. Oznacza to, że nowe wiersze nie mogą zostać zapisane z powodu przekroczenia rozmiaru tabeli tymczasowej. Szczegółowy komunikat błędu może wyglądać tak:

Zaloguj się do MySQL:

# mysql -u root -p

1	# mysql -u root -p

Zmień wartości zmiennej:

SET GLOBAL tmp_table_size = 268435456;  -- Ustawienie na 256M
SET GLOBAL max_heap_table_size = 268435456;  -- Ustawienie na 256M

1 2	SET GLOBAL tmp_table_size = 268435456; -- Ustawienie na 256M SET GLOBAL max_heap_table_size = 268435456; -- Ustawienie na 256M

Po wprowadzeniu tych zmian, wszystkie nowe połączenia do serwera MySQL będą używać tych zaktualizowanych wartości. Możesz je sprawdzić, wykonując:

SHOW GLOBAL VARIABLES LIKE 'tmp_table_size';
SHOW GLOBAL VARIABLES LIKE 'max_heap_table_size';

1 2	SHOW GLOBAL VARIABLES LIKE 'tmp_table_size'; SHOW GLOBAL VARIABLES LIKE 'max_heap_table_size';

Albo

SELECT @@tmp_table_size, @@max_heap_table_size;

1	SELECT @@tmp_table_size, @@max_heap_table_size;

Teraz replikacje można wznowić i powinna lepiej działać. Jednak należy pamiętaj, o modyfikacji konfiguracji, aby po restarcie mysqla zmienne te zostały poprawnie ustawione. Może być koniecznie tutaj wznowienie np replikacji (jeśli wcześniej została zatrzymana):

START SLAVE;

1	START SLAVE;

Jeśli problem został rozwiązany, na tym etapie sprawdzenie stanu replikacji:

show slave status \G

1	show slave status \G

Nie powinien zwracać żadnych błędów.

Modyfikacja pliku konfiguracyjnego /etc/mysql/my.cnf:

# cat /etc/mysql/my.cnf
...
tmp_table_size=256M
max_heap_table_size=256M
...

# cat /etc/mysql/my.cnf

...

tmp_table_size=256M

max_heap_table_size=256M

...

Restart usługi MySQL:

# systemctl restart mysql

1	# systemctl restart mysql

Przed restartem usługi zalecane jest wykonanie SHUTDOWN; w kliencie MySQL.
Należy pamiętać o wznowieniu replikacji.

Ważne uwagi

Zasoby systemowe: Upewnij się, że serwer dysponuje wystarczającą ilością pamięci RAM do obsługi zwiększonych wartości zmiennych.
Monitoring wydajności: Po dokonaniu zmian monitoruj wydajność, aby sprawdzić, czy problem został rozwiązany.
Trwałość konfiguracji: Zmiany w pliku konfiguracyjnym powinny być trwałe, aby uniknąć resetowania wartości po restarcie.

Dodatkowe kroki sprawdzające

Sprawdzenie dostępnej przestrzeni dyskowej: Możliwe, że problem wynika również z braku dostępnej przestrzeni na dysku. Można to sprawdzić za pomocą poniższej komendy:

# df -h

# df -h

Podsumowanie

Rozwiązanie problemu związanego z kodem błędu 1114 w replikacji MySQL wymaga zrozumienia i dostosowania konfiguracji systemu. Opisane kroki pokazują, jak poprzez zwiększenie rozmiaru tabeli tymczasowej można zapobiec występowaniu tego błędu, co umożliwia sprawne działanie systemu replikacji.