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


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:

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.

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:

Skrypt pracuje do osiągniecia 70%

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:

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

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

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

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.

Możesz też pobrać skrypt:

Nie zapomnij o nadaniu uprawnień do uruchamiania go:

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.

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

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.

Oto przykład wyniku polecenia lsblk na maszynie:

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.

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.

Zapis zmian

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

Wykonanie pvscan

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

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.

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

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

oraz:

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

Oczekiwany output:

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

Oczekiwany output:

Usuwanie pliku konfiguracyjnego kontenera i czyszczenie danych

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

Output:

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

Przywracanie kontenera

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

Output:

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


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:

Utworzenie nowego schematu Performance Schema w MySQL

Tworzenie nowego schematu performance schema z linii komend MySQL:

Operacje serwerowe do ustanowienia nowego środowiska MySQL

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

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

Konfiguracja i weryfikacja w MySQL

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

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

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

Konfiguracji MySQL na serwerze w celu uruchomienia nowej bazy danych

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

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

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:

Należy wyłączyć mysqla:

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

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

Nie zapomnij usunąć śmieci:

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

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:

Inicjalizacja biletu Kerberos

Zainicjuj bilet Kerberos za pomocą poniższego polecenia:

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

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:

Automatyczne montowanie przez fstab

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

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

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

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.

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:

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

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

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.

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

Krok 3: Użycie lvreduce

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

Krok 4: Deaktywacja SWAP

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

Krok 5: Rozszerzenie SWAP

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

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


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:

Zmień wartości zmiennej:

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:

Albo


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

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

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

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

Restart usługi 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:

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

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:

Ten skrypt wykonuje następujące operacje:

  1. Generuje aktualną datę i czas, które są dodawane do nazwy tworzonego archiwum, aby łatwo można było identyfikować poszczególne kopie.
  2. Używa programu tar z kompresją zstd do stworzenia zarchiwizowanej i skompresowanej kopii katalogu /etc.
  3. 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:

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:

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.