Archiwa Linux

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.

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.