soban - IT, Linux, Servers, Security

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.

Automatyzacja Procesu Backupu w Proxmox: Praktyczny Skrypt i Konfiguracja Crontab

Posted on 16 kwietnia, 202416 kwietnia, 2024 by soban

W dzisiejszych czasach, gdy dane stają się coraz bardziej wartościowe, odpowiednie zarządzanie backupami jest kluczowe dla bezpieczeństwa systemu informatycznego. W tym artykule przedstawiam skuteczny sposób na automatyzację backupu kluczowych plików konfiguracyjnych w systemach opartych na Proxmox za pomocą prostego skryptu bash oraz konfiguracji Crontab.

Skrypt Bash do Backupu Katalogu `/etc`

Plik /etc zawiera krytyczne pliki konfiguracyjne systemu, które są niezbędne do prawidłowego funkcjonowania systemu operacyjnego i różnych aplikacji. Utrata lub uszkodzenie tych plików może prowadzić do poważnych problemów. Poniżej prezentuję skuteczny skrypt backup-etc.sh, który pozwala na zautomatyzowane tworzenie kopii zapasowych tego katalogu:

#!/bin/bash
date_now=$(date +%Y_%m_%d-%H_%M_%S)
tar --use-compress-program zstd -cf /var/lib/vz/dump/vz-etc-$(hostname)-$date_now.tar.zst /etc/
find /var/lib/vz/dump/ -name vzup1-etc-* -type f -mtime +100 | xargs rm -f

#!/bin/bash

date_now=$(date +%Y_%m_%d-%H_%M_%S)

tar --use-compress-program zstd -cf /var/lib/vz/dump/vz-etc-$(hostname)-$date_now.tar.zst /etc/

find /var/lib/vz/dump/ -name vzup1-etc-* -type f -mtime +100 | xargs rm -f

Ten skrypt wykonuje następujące operacje:

Generuje aktualną datę i czas, które są dodawane do nazwy tworzonego archiwum, aby łatwo można było identyfikować poszczególne kopie.
Używa programu tar z kompresją zstd do stworzenia zarchiwizowanej i skompresowanej kopii katalogu /etc.
Usuwa archiwa starsze niż 100 dni z lokalizacji /var/lib/vz/dump/, dzięki czemu zapewniona jest optymalizacja przestrzeni dyskowej.

Dodanie Skryptu do Crontab

Aby automatyzować proces tworzenia backupu, skrypt należy dodać do crontaba. Poniżej znajduje się przykładowa konfiguracja, która uruchamia skrypt codziennie o 2:40 nad ranem:

# crontab -e
40 2 * * * /root/backup-etc.sh > /dev/null 2>&1

1 2	# crontab -e 40 2 * * * /root/backup-etc.sh > /dev/null 2>&1

Przekierowanie wyjścia do /dev/null zapewnia, że operacje są wykonywane cicho bez generowania dodatkowego outputu na standardowe wyjście.

Pobranie Skryptu z Serwisu soban.pl

Skrypt backup-etc.sh jest dostępny do pobrania również z serwisu soban.pl. Możesz go pobrać za pomocą poniższego polecenia wget i od razu zapisać jako plik /root/backup-etc.sh:

# wget -O /root/backup-etc.sh https://soban.pl/bash/backup-etc.sh && chmod +x /root/backup-etc.sh

1	# wget -O /root/backup-etc.sh https://soban.pl/bash/backup-etc.sh && chmod +x /root/backup-etc.sh

Dzięki temu prostemu poleceniu, skrypt zostanie pobrany z serwera i nadany odpowiednie uprawnienia wykonywalności.

Korzyści i Modyfikacje

Skrypt backup-etc.sh jest elastyczny i można go łatwo modyfikować do potrzeb różnych systemów. Jest on domyślnie umieszczony w folderze /var/lib/vz/dump/, który jest standardowym miejscem przechowywania backupów w środowiskach Proxmox. Dzięki temu zarządzanie kopiami zapasowymi jest uproszczone i można je łatwo zintegrować z istniejącymi rozwiązaniami backupowymi.

Trzymając backupy przez 100 dni, zapewniamy równowagę między dostępnością a zarządzaniem przestrzenią dyskową. Stare kopie są automatycznie usuwane, co minimalizuje ryzyko przepełnienia dysku i zmniejsza koszty przechowywania danych.

Podsumowanie

Automatyzacja backupu za pomocą skryptu bash i Crontab to efektywna metoda na zabezpieczenie krytycznych danych systemowych. Skrypt backup-etc.sh zapewnia prostotę, elastyczność i efektywność, co czyni go doskonałym rozwiązaniem dla administratorów systemów Proxmox. Zachęcam do adaptacji i modyfikacji tego skryptu zgodnie z własnymi potrzebami, aby zapewnić jeszcze lepsze zabezpieczenie swojego środowiska IT.

Aktualizowanie Apache Cassandra z wersji 3.1.15 i nowszych do 4.1.x w systemie Ubuntu 20.04.5 LTS: kompleksowy przewodnik

Posted on 16 kwietnia, 202416 kwietnia, 2024 by soban

Aktualizacja Apache Cassandra do nowszej wersji to znaczące zadanie, które administratorzy baz danych podejmują, aby ich systemy korzystały z nowych funkcji, ulepszonych środków bezpieczeństwa i poprawionej wydajności. Ten przewodnik dostarcza szczegółowych instrukcji dotyczących aktualizacji Apache Cassandra z wersji 3.1.15 i wyższych do najnowszej wersji 4.1.x, specjalnie na Ubuntu 20.04.5 LTS, ze szczególnym naciskiem na operacje czyszczenia przed aktualizacją, aby efektywnie zarządzać przestrzenią dyskową.

Przygotowanie przed aktualizacją

Kopia zapasowa katalogu konfiguracyjnego:

Przed rozpoczęciem aktualizacji kluczowe jest wykonanie kopii zapasowej katalogu konfiguracyjnego Cassandry. To zabezpieczenie umożliwia szybkie przywrócenie konfiguracji, jeśli podczas procesu aktualizacji pojawią się jakiekolwiek problemy. Wykorzystaj poniższe polecenie, aby stworzyć kopię zapasową, włączając do nazwy folderu bieżącą datę dla łatwej identyfikacji:

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

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

Operacje czyszczenia przed aktualizacją

Przygotowanie jest kluczem do płynnej aktualizacji. Zacznij od poleceń konserwacyjnych, aby zagwarantować integralność danych i zoptymalizować wykorzystanie przestrzeni, co jest szczególnie ważne dla systemów z ograniczoną przestrzenią dyskową.

Oczyszczanie danych:

Wykonaj nodetool scrub, aby oczyścić i zreorganizować dane na dysku. Biorąc pod uwagę, że ta operacja może być czasochłonna, zwłaszcza dla baz danych z dużą ilością danych lub ograniczoną przestrzenią dyskową, jest to kluczowy krok dla zdrowego procesu aktualizacji.

Usuwanie snapshota:

Aby dalej zarządzać przestrzenią dyskową, użyj nodetool clearsnapshot do usunięcia istniejących snapshota, zwalniając miejsce na proces aktualizacji. Aby usunąć wszystkie migawki na węźle, po prostu użyj tej metody, jeśli kończy Ci się miejsce:

# nodetool clearsnapshot --all

1	# nodetool clearsnapshot --all

Czyszczenie danych:

Wykonaj nodetool cleanup, aby usunąć zbędne dane. W scenariuszach, gdzie przestrzeń dyskowa jest na wagę złota, zaleca się wykonanie operacji oczyszczania bez tworzenia migawki, aby oszczędzić miejsce:

# nodetool scrub --no-snapshot

1	# nodetool scrub --no-snapshot

Opróżnianie i zatrzymywanie Cassandry

Opróżnienie węzła:

Przed zatrzymaniem usługi Cassandra, upewnij się, że wszystkie dane w pamięci są zapisane na dysku za pomocą nodetool drain.

# nodetool drain

1	# nodetool drain

Zatrzymaj usługę Cassandry:

Zatrzymaj działające usługi Cassandry, aby bezpiecznie przystąpić do aktualizacji:

# systemctl stop cassandra.service

1	# systemctl stop cassandra.service

Aktualizacja Cassandry

Aktualizacja listy źródeł:

Edytuj źródła repozytorium, aby wskazywały na nową wersję Cassandry, dostosowując plik cassandra.sources.list:

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

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

Aktualizacja pakietów:

Przy zaktualizowanych źródłach repozytorium, odśwież listę pakietów i zaktualizuj pakiety. Podczas wykonywania polecenia apt upgrade, możesz kontynuować naciskając Enter, ponieważ domyślna opcja to 'N’ (Nie):

# apt update && apt upgrade

1	# apt update && apt upgrade

Modyfikacja konfiguracji:

Dostosuj konfigurację Cassandry dla wersji 4.1.x, komentując lub usuwając przestarzałe opcje:

# 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

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

Aktualizacja biblioteki JAMM:

Upewnij się, że biblioteka Java Agent Memory Manager (JAMM) jest zaktualizowana, aby poprawić wydajność:

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

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

Zapasowa kopia i aktualizacja pliku opcji JVM:

Jest dobrą praktyką tworzenie kopii zapasowych plików konfiguracyjnych przed dokonaniem zmian. Ten krok zmienia nazwę istniejącego pliku jvm-server.options na jvm-server.options.orig jako kopię zapasową. Następnie kopiuje plik jvm.options do jvm-server.options, stosując standardowe opcje JVM dla serwerów Cassandry.

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

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

Optymalizacja i weryfikacja

Optymalizacja wykorzystania pamięci:

Po aktualizacji warto ocenić i zoptymalizować wykorzystanie pamięci i przestrzeni wymiany, aby zapewnić efektywne działanie Cassandry:

# swapoff -a && swapon -a

1	# swapoff -a && swapon -a

Uruchom ponownie usługę Cassandry:

# systemctl start cassandra.service

1	# systemctl start cassandra.service

Weryfikacja aktualizacji:

Potwierdź sukces aktualizacji, sprawdzając topologię i stan klastra, upewniając się, że wszystkie węzły są funkcjonalne:

# nodetool describecluster
# nodetool status

1 2	# nodetool describecluster # nodetool status

Przestrzegając tego szczegółowego przewodnika, administratorzy baz danych mogą skutecznie aktualizować Apache Cassandra do wersji 4.1.x, wykorzystując najnowsze postępy i optymalizacje, które platforma ma do zaoferowania, jednocześnie zapewniając integralność danych i wydajność systemu dzięki starannym przygotowaniom przed aktualizacją.

Optymalizacja i weryfikacja

Po pomyślnej aktualizacji Apache Cassandra do wersji 4.1.x i upewnieniu się, że klaster jest w pełni operacyjny, kluczowe jest przeprowadzenie konserwacji po aktualizacji, aby zoptymalizować wydajność i bezpieczeństwo systemu bazy danych. Ta sekcja przedstawia niezbędne kroki i rozważania, aby utrzymać zdrowe i efektywne środowisko Cassandry.

Monitorowanie wydajności i dzienników

Bezpośrednio po aktualizacji ściśle monitoruj wydajność systemu, w tym użycie procesora, pamięci i I/O dysków, aby zidentyfikować wszelkie nieoczekiwane zachowania lub wąskie gardła. Dodatkowo, przejrzyj dzienniki systemowe Cassandry pod kątem ostrzeżeń lub błędów, które mogą wskazywać na potencjalne problemy wymagające uwagi.

Regulacja i optymalizacja

Na podstawie wglądu w monitorowanie wydajności, możesz potrzebować dostosować ustawienia konfiguracyjne Cassandry dla optymalnej wydajności. Rozważ regulację parametrów związanych z opcjami JVM, kompaktacją i wydajnością odczytu/zapisu, mając na uwadze specyficzne obciążenie i wzorce danych Twojej aplikacji.

Uruchom nodetool upgradesstables

Aby upewnić się, że wszystkie SSTables są zaktualizowane do najnowszego formatu, wykonaj nodetool upgradesstables na każdym węźle w klastrze. Ta operacja przepisze SSTables, które nie są jeszcze w bieżącym formacie, co jest niezbędne do pełnego wykorzystania ulepszeń i funkcji w Cassandra 4.1.x (Sprawdź przestrzeń i w razie potrzeby usuń wszystkie migawki, jak pokazano powyżej.):

# time nodetool upgradesstables

1	# time nodetool upgradesstables

Ten proces może być obciążający dla zasobów i powinien być zaplanowany poza godzinami szczytu, aby zminimalizować wpływ na ruch na żywo.

Wdrożenie ulepszeń bezpieczeństwa

Cassandra 4.1.x zawiera kilka ulepszeń bezpieczeństwa. Przejrzyj najnowsze funkcje bezpieczeństwa i najlepsze praktyki, takie jak włączenie szyfrowania klient-serwer, szyfrowanie węzeł-węzeł oraz zaawansowane mechanizmy uwierzytelniania, aby poprawić poziom bezpieczeństwa klastra Cassandry.

Przegląd i aktualizacja strategii tworzenia kopii zapasowych

Z nową wersją na miejscu, ponownie ocen swoje strategie tworzenia kopii zapasowych, aby upewnić się, że są nadal skuteczne i spełniają Twoje cele odzyskiwania. Zweryfikuj, czy Twoje procedury tworzenia kopii zapasowych i przywracania są zgodne z Cassandra 4.1.x oraz rozważ wykorzystanie nowych narzędzi lub funkcji, które mogły zostać wprowadzone w tej wersji dla bardziej efektywnego zarządzania danymi.

Uproszczona instalacja Proxmox VE 8 na Debianie 12 Bookworm

Posted on 22 lutego, 202419 kwietnia, 2024 by soban

Proxmox VE to zaawansowana platforma do zarządzania serwerami open source, która integruje hypervisor KVM oraz kontenery LXC. Prezentujemy uproszczony proces instalacji Proxmox VE 8 na Debianie 12 Bookworm, oparty na oficjalnym przewodniku instalacji Proxmox VE – Proxmox VE Installation Guide.

Wymagania wstępne:

Świeża instalacja Debiana 12 Bookworm.
Użytkownik z uprawnieniami sudo.
Dostęp do Internetu.

Skrypty instalacyjne

Podzieliliśmy proces instalacji na dwa skrypty. Pierwszy skrypt przygotowuje system i instaluje jądro Proxmox VE. Drugi skrypt kontynuuje proces po restarcie systemu, instalując pozostałe pakiety Proxmox VE.

Pamiętaj, że wszystkie komendy należy wykonać z poziomu użytkownika root, więc:

# sudo su -

1	# sudo su -

Pierwsza część: Przygotowanie systemu i instalacja jądra

Rozpocznij od pobrania pierwszego skryptu, który przygotuje Twój system i zainstaluje jądro Proxmox VE:

# wget https://soban.pl/bash/install-proxmox-part1.sh
# chmod +x install-proxmox-part1.sh

1 2	# wget https://soban.pl/bash/install-proxmox-part1.sh # chmod +x install-proxmox-part1.sh

Uruchom skrypt następującym poleceniem:

# ./install-proxmox-part1.sh

1	# ./install-proxmox-part1.sh

Oto zawartość skryptu:

#!/bin/bash
# The script is an integral part of the article available at (part 1/2)
# https://soban.pl/simplified-proxmox-ve-8-installation-on-debian-12-bookworm/

# Introduction message
echo "Starting the setup for Proxmox VE installation on Debian Bookworm..."

# Display available network interfaces and their IP addresses
echo "Available network interfaces and IP addresses:"
ip -br -c a

# Retrieve the current hostname
CURRENT_HOSTNAME=$(hostname)

# Retrieve the current IP address
CURRENT_IP_ADDRESS=$(hostname -I | awk '{print $1}')

# Set up hostname
echo "Please enter the hostname for your Proxmox server (Press Enter to keep current: $CURRENT_HOSTNAME):"
read HOSTNAME
if [ -z "$HOSTNAME" ]; then
    HOSTNAME=$CURRENT_HOSTNAME
fi

# Set up IP address
echo "Based on the list above, please enter the IP address for your Proxmox server (Press Enter to keep current: $CURRENT_IP_ADDRESS):"
read IPADDRESS
if [ -z "$IPADDRESS" ]; then
    IPADDRESS=$CURRENT_IP_ADDRESS
fi

hostnamectl set-hostname "$HOSTNAME"

# Backup and configure /etc/hosts
cp /etc/hosts /etc/hosts.backup
cat <<EOF > /etc/hosts
127.0.0.1       localhost
$IPADDRESS      $HOSTNAME

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
EOF

# Backup existing sources.list and prepare Proxmox VE repository
cp /etc/apt/sources.list /etc/apt/sources.list.backup
echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

# Add the Proxmox VE repository key
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
echo "Verifying the GPG key..."
sha512sum /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg | grep '7da6fe34168adc6e479327ba517796d4702fa2f8b4f0a9833f5ea6e6b48f6507a6da403a274fe201595edc86a84463d50383d07f64bdde2e3658108db7d6dc87'
if [ $? -ne 0 ]; then
    echo "GPG key verification failed. Aborting."
    exit 1
fi

# Update and upgrade the system
apt update && apt full-upgrade -y

# Install the Proxmox VE kernel
apt install proxmox-default-kernel -y

# Install Proxmox VE and other necessary packages
apt install proxmox-ve postfix open-iscsi chrony -y

echo "Kernel installation completed. The system will now reboot. After rebooting, continue with the second part of the script."
reboot

#!/bin/bash

# The script is an integral part of the article available at (part 1/2)

# https://soban.pl/simplified-proxmox-ve-8-installation-on-debian-12-bookworm/

# Introduction message

echo "Starting the setup for Proxmox VE installation on Debian Bookworm..."

# Display available network interfaces and their IP addresses

echo "Available network interfaces and IP addresses:"

ip -br -c a

# Retrieve the current hostname

CURRENT_HOSTNAME=$(hostname)

# Retrieve the current IP address

CURRENT_IP_ADDRESS=$(hostname -I | awk '{print $1}')

# Set up hostname

echo "Please enter the hostname for your Proxmox server (Press Enter to keep current: $CURRENT_HOSTNAME):"

read HOSTNAME

if [ -z "$HOSTNAME" ]; then

HOSTNAME=$CURRENT_HOSTNAME

# Set up IP address

echo "Based on the list above, please enter the IP address for your Proxmox server (Press Enter to keep current: $CURRENT_IP_ADDRESS):"

read IPADDRESS

if [ -z "$IPADDRESS" ]; then

IPADDRESS=$CURRENT_IP_ADDRESS

hostnamectl set-hostname "$HOSTNAME"

# Backup and configure /etc/hosts

cp /etc/hosts /etc/hosts.backup

cat <<EOF > /etc/hosts

127.0.0.1 localhost

$IPADDRESS $HOSTNAME

# The following lines are desirable for IPv6 capable hosts

::1 localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

EOF

# Backup existing sources.list and prepare Proxmox VE repository

cp /etc/apt/sources.list /etc/apt/sources.list.backup

echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

# Add the Proxmox VE repository key

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

echo "Verifying the GPG key..."

sha512sum /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg | grep '7da6fe34168adc6e479327ba517796d4702fa2f8b4f0a9833f5ea6e6b48f6507a6da403a274fe201595edc86a84463d50383d07f64bdde2e3658108db7d6dc87'

if [ $? -ne 0 ]; then

echo "GPG key verification failed. Aborting."

exit 1

# Update and upgrade the system

apt update && apt full-upgrade -y

# Install the Proxmox VE kernel

apt install proxmox-default-kernel -y

# Install Proxmox VE and other necessary packages

apt install proxmox-ve postfix open-iscsi chrony -y

echo "Kernel installation completed. The system will now reboot. After rebooting, continue with the second part of the script."

reboot

Po uruchomieniu pierwszego skryptu system zostanie ponownie uruchomiony. Na tym etapie mogą pojawić się różne dialogi systemowe, które są częścią standardowych kroków konfiguracji pakietów. Dla tej uproszczonej instalacji można zaakceptować domyślne opcje, naciskając Enter.

Zrzuty ekranu podczas instalacji

The selection of GRUB installation configuration.

Konfiguracja GRUB – dostępna jest nowa wersja pliku konfiguracyjnego bootloadera GRUB. Zaleca się zachowanie aktualnie zainstalowanej wersji lokalnej, chyba że jesteś świadomy zmian. Tak jak w przypadku poprzednich dialogów, naciśnięcie Enter wybierze domyślną akcję.

The selection of postfix installation configuration.

Konfiguracja Postfix – ten dialog pojawia się podczas instalacji pakietu postfix, który jest agentem transportu poczty. Domyślna opcja „Internet Site” jest odpowiednia dla większości przypadków. Naciśnięcie Enter akceptuje tę konfigurację.

System Mail Name – tutaj określasz FQDN (Fully Qualified Domain Name) dla poczty systemowej. Domyślna wartość jest zazwyczaj odpowiednia, chyba że masz określoną nazwę domeny dla swojego serwera. Ponownie, naciśnięcie Enter kontynuuje z domyślną konfiguracją.

Możliwe problemy napotkane pod koniec instalacji pierwszego skryptu, takie jak:

Errors were encountered while processing:
 ifupdown2
 pve-manager
 proxmox-ve
E: Sub-process /usr/bin/dpkg returned an error code (1)

Errors were encountered while processing:

ifupdown2

pve-manager

proxmox-ve

E: Sub-process /usr/bin/dpkg returned an error code (1)

Jednak druga część skryptu, wykonana po restarcie, rozwiązuje te problemy. Po pomyślnym restarcie maszyny zaloguj się do systemu i kontynuuj z drugim skryptem.

Druga część: Zakończenie instalacji Proxmox VE

Po restarcie systemu kontynuuj pobieranie drugiego skryptu:

# wget https://soban.pl/bash/install-proxmox-part2.sh
# chmod +x install-proxmox-part2.sh

1 2	# wget https://soban.pl/bash/install-proxmox-part2.sh # chmod +x install-proxmox-part2.sh

Wykonaj drugą część instalacji za pomocą polecenia:

# ./install-proxmox-part2.sh

1	# ./install-proxmox-part2.sh

Oto zawartość drugiego skryptu:

#!/bin/bash
# The script is an integral part of the article available at (part 2/2)
# https://soban.pl/simplified-proxmox-ve-8-installation-on-debian-12-bookworm/

# Introduction message
echo "Continuing Proxmox VE installation after reboot..."

# Install upgrade
apt upgrade -y

# Optional: Remove the Debian default kernel
apt remove linux-image-amd64 'linux-image-6.1*' -y
update-grub

# Optionally remove the os-prober package
apt remove os-prober -y

# Clean up installation repository entry
rm /etc/apt/sources.list.d/pve-install-repo.list

# Retrieve the server's IP address for the Proxmox web interface link
IP_ADDRESS=$(hostname -I | awk '{print $1}')
echo "Proxmox VE installation completed."
echo "You can now connect to the Proxmox VE web interface using:"
echo "https://$IP_ADDRESS:8006"
echo "Please log in using the 'root' username and your root password."

#!/bin/bash

# The script is an integral part of the article available at (part 2/2)

# https://soban.pl/simplified-proxmox-ve-8-installation-on-debian-12-bookworm/

# Introduction message

echo "Continuing Proxmox VE installation after reboot..."

# Install upgrade

apt upgrade -y

# Optional: Remove the Debian default kernel

apt remove linux-image-amd64 'linux-image-6.1*' -y

update-grub

# Optionally remove the os-prober package

apt remove os-prober -y

# Clean up installation repository entry

rm /etc/apt/sources.list.d/pve-install-repo.list

# Retrieve the server's IP address for the Proxmox web interface link

IP_ADDRESS=$(hostname -I | awk '{print $1}')

echo "Proxmox VE installation completed."

echo "You can now connect to the Proxmox VE web interface using:"

echo "https://$IP_ADDRESS:8006"

echo "Please log in using the 'root' username and your root password."

Po zakończeniu działania drugiego skryptu, uzyskasz dostęp do interfejsu webowego Proxmox VE za pomocą adresu URL wyświetlonego na końcu skryptu. Zaloguj się używając nazwy użytkownika ‘root’ oraz swojego hasła root.

Podczas ładowania strony, możesz napotkać błąd zaufania certyfikatu – jest to normalne na tym etapie i bezpiecznie możesz zaakceptować, że jest to niebezpieczne i kontynuować dostęp do strony zarządzania Proxmox. Jeśli nie znasz hasła root, możesz je zresetować, wykonując ‘passwd‘ jako root. Powodzenia!

Wstępne przygotowania

Tworzenie snapshotów

Modyfikacja partycji

Zapis zmian

Wykonanie pvscan

Konfiguracja LVM

Podsumowanie

Diagnostyka stanu klastra Proxmox

Usuwanie pliku konfiguracyjnego kontenera i czyszczenie danych

Przywracanie kontenera

Początkowa diagnoza w MySQL

Utworzenie nowego schematu Performance Schema w MySQL

Operacje serwerowe do ustanowienia nowego środowiska MySQL

Konfiguracja i weryfikacja w MySQL

Konfiguracji MySQL na serwerze w celu uruchomienia nowej bazy danych

Eksportuj i przywróć schemat Performance Schema w MySQL

Inicjalizacja biletu Kerberos

Ręczne montowanie zasobów

Automatyczne montowanie przez fstab

Podsumowanie

Krok 1: Dostęp do pliku konfiguracyjnego

Krok 2: Modyfikacja ustawień logind

Krok 3: Zastosowanie i restart usługi

Przegląd problemu

Krok 1: Sprawdzenie dostępnej przestrzeni

Krok 2: Zmniejszenie wolumenu

Krok 3: Użycie lvreduce

Krok 4: Deaktywacja SWAP

Krok 5: Rozszerzenie SWAP

Wprowadzenie

Opis problemu

Ważne uwagi

Dodatkowe kroki sprawdzające

Podsumowanie

Skrypt Bash do Backupu Katalogu /etc

Dodanie Skryptu do Crontab

Pobranie Skryptu z Serwisu soban.pl

Korzyści i Modyfikacje

Podsumowanie

Przygotowanie przed aktualizacją

Opróżnianie i zatrzymywanie Cassandry

Aktualizacja Cassandry

Optymalizacja i weryfikacja

Wymagania wstępne:

Skrypty instalacyjne

Pierwsza część: Przygotowanie systemu i instalacja jądra

Zrzuty ekranu podczas instalacji

Druga część: Zakończenie instalacji Proxmox VE

Skrypt Bash do Backupu Katalogu `/etc`