K-NET s.c.

openmediavault NAS

openmediavault to projekt, którego popularność wzrasta nieustannie od kilku ładnych lat. Jest to gotowy do użytku zestaw aplikacji pozwalający na zbudowanie własnego serwera NAS w systemie opartym o Debian Linux. W dobie dwóch bardzo dobrych komercyjnych rozwiązań, którymi są produkty firm Synology i QNAP wydawać by się mogło, że kolejny gracz nie jest już potrzebny. Jednak openmediavault to rozwiązania wręcz perfekcyjne jeśli dysponujemy starym serwerem i nie chcemy wydawać pieniądzy żeby przygotować sobie maszynę na kopie zapasowe.

Tym razem jednak chciałbym napisać o alternatywnej metodzie instalacji openmediavault. Ze strony www.openmediavault.org możemy pobrać gotowe obrazy ISO tak aby przeprowadzić standardową instalację tak jak w przypadku każdego systemu operacyjnego tzn. z nośnika USB lub płyty DVD ale istnieje również inna metoda.

Wyobraźmy sobie, że mamy już sewer z Debianem i chcielibyśmy wzbogcić go o nakładkę w postaci openmediavault. Tego typu instalacja nie musi być pozbawiona sensu, zwłaszcza że wraz z oprogramowaniem dostaniemy wygodne narzędzie GUI do utrzymywania środowiska z kontenerami typu Docker plus Portainer czy narzędzie do zarządzania wirtualizacją Linux KVM. Jakby tego było mało – dodatkowo jeśli nie myślimy o zaawansowanej pracy z serwerem Debian – to przy odrobinie samozaparcia możemy w całości zarządzać systemem przy pomocy wspomnianego wyżej GUI.

Co zatem należy zrobić? Trzeba z poziomu konsoli systemowej uruchomić skrypt:

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install |  bash

Jeśli zaś nie używamy wget możemy to zrobić tak:

curl -sSL https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install |  bash

Po kilku, kilkunastu minutach powinniśmy mieć zainstalowaną nakładkę openmediavault.

Jeśli nadal coś nie będzie działać lub pojawią się dodatkowe problemy to polecam sprawdzić u źródeł na stronie GitHub OpenMediaVault Plugin Developers w sekcji installScript.

MG

Tagi: Debian, konfiguracja, Linux, OMV

Linux Debian ELTS

Linux Debian to niewątpliwie jedna z bazowych dystrybucji, przynajmniej do tej pory tak zawsze pisano na rozmaitych wiki – pozostałe dwie to rodziny RedHat i Slackware. Osobiście bardzo ją lubię, w głównej mierze za prostotę i dosyć logicznie poukładany system operacyjny. Od wielu lat twierdzę, że dużo łatwiej nauczyć się dobrze posługiwać Debianem niż MS Windows (sic!). W wersji instalacji sieciowej można za pomocą kilku komend dostać naprawdę dobrze skrojony system i co ważne bez zbędnych dodatków. Dla porównania w Ubuntu, które wykorzystuje Debiana już nie jest tak wydajnie.

Czy istnieją jednak jakieś niedogodności Debiana, a być może wady? Świat byłby zbyt piękny gdyby istniał ideał. Jak się zapewne domyślacie musi być coś co denerwuje nawet tak oddanych użytkowników jak autor tego wpisu. I rzeczywiście można wymienić zapewne kilka ułomności, z których mi najbardziej przeszkadza cykl wydawniczy kolejnych wersji. A w zasadzie jego długość (bądź krótkość żeby być bardziej precyzyjnym).

Debian przede wszystkim stara się być bardzo stabilny. Zatem wszelkie nowości pojawiają się z dużym opóźnieniem w stosunku do innych dystrybucji. Najpierw każdy z pakietów jest testowany a dopiero później – jeżeli wszystko będzie w porządku według deweloperów – włączany do głównego repozytorium. To zajmuje sporo czasu. Co dwa lata pojawia się nowe główne wydanie a wsparcie przewidziane jest na trzy. Jeśli wybierzemy wersję hmm… długowieczną tzw. long life LTS to otrzymamy aktualizacje do pięciu lat od momentu debiutu. Można powiedzieć, że ten sposób dystrybucji jest optymalny ale dobrze wiadomo, że trzy lata potrafią minąć bardzo szybko. Wsparcie kończy się nagle. Nowe pakiety nie pojawiają się w repozytorium a my zostajemy z przeterminowanym serwerem. Prawdę mówiąc jeżeli utrzymujemy jeden taki serwer to wymiana systemu może być pracochłonna ale stosunkowo bezbolesna. Aktualizacji typu distroupgrade dystrybucji nie polecam. Raz tak zrobiłem i bardzo żałowałem. Inaczej sprawa wygląda jeśli hostów z przestarzałym Debianem mamy kilka lub kilkanaście.

Wychodząc naprzeciw potrzebom sysopsów w dużych sieciach serwerów niektórzy dostawcy oprogramowania oferują swoje repozytoria, które pozwalają przedłużyć życie naszych węzłów poza wsparcie LTS. Naprawdę warto poszukać w sieci. Przykładem z mojej praktyki jest Debian Jessie, którego wsparcie skończyło się 30 czerwca 2020 roku. Okazało się jednak, że jest dosyć popularna dystrybucja (a admini dosyć leniwi) i społeczność zaczęła pracować nad alternatywnymi repozytoriami.

Mamy pierwszy kwartał 2022 roku, dwa lata po terminie a nadal wychodzą aktualizacje. Jednak należy ich szukać na stronie (czyli jak wspominałem poza oficjalnym źródłem):

https://deb.freexian.com/extended-lts/

Projekt nazywa się Debian Extended LTS (ELTS) i jest odpowiedzią na zapotrzebowanie rynku. Zupełnie inną sprawą jest pytanie czy jest to właściwy sposób rozwiązania problemu? Z różnych względów zapewne nie. Ale potrzeba i lenistwo są matką wynalazków. Zatem jeśli nie widzisz innego wyjścia to możesz użyć ELTS ale pamiętaj, że również to repozytorium przestanie być kiedyś używane.

MG

Tagi: Debian, konfiguracja, Linux

ESXI linia poleceń

Wielokrotnie na łamach bloga chwaliłem VMware ESXi jako jedno z najlepszych rozwiązań dla wirtualizacji. Ostatnio bawiłem się trochę maszynami KVM i… po raz kolejny mogę z czystym sumieniem polecić to pierwsze rozwiązanie. Wiem, że na KVM można robić cuda, ale codzienna praktyka sysadmina, gdy zadania mnożą się jak grzyby po deszczu i nie ma na nic czasu powoduje, że trzeba używać rozwiązań stanowiących kompromis pomiędzy elastycznością a szybkością wdrożenia.

Oczywiście ESXi w wersji powyżej 6.5 to bardzo wygodny interfejs graficzny do zarządzania. Wyklikać można wiele rzeczy i trzeba przyznać, że całość jest logicznie i przejrzyście poukładana. Myślę, że średniozaawansowany użytkownik nawet nie będzie potrzebował instrukcji użytkownika, żeby samemu dojść do pożądanej konfiguracji.

Są jednak sytuacje, w których przydaje się shell systemowy. Zwłaszcza gdy stoimy dosłownie przed serwerem ESXi i widzimy słynny niebiesko żółty ekran powitalny trybu tekstowego. Możemy również uruchomić usługę SSH i zdalnie zaologować się jako root do konsoli. VMware to tak naprawdę Photon OS Linux, czyli dystrybucja skrojona na miarę hosta maszyn wirtualnych. Powinny być zatem dostępne typowe komendy linuksowe i rzeczywiście tak jest. Ale aby zarządzać samymi maszynami potrzebujemy kilku poleceń ekstra. Poniżej przedstawiam absolutnie minimalną listę tych najbardziej potrzebnych.

Aby wyświetlić listę maszyn zainstalowanych na hoście używamy komendy:

vim-cmd vmsvc/getallvms

Zwracam uwagę na pierwszą kolumnę, w której znajdziemy identyfikator <vmid>.

Aby wyłączyć maszynę używamy polecenia:

vim-cmd vmsvc/power.off <vmid>

Aby zrobić to w kulturalny sposób:

vim-cmd vmsvc/power.shutdown <vmid>

Analogicznie by ją włączyć:

vim-cmd vmsvc/power

A na koniec tryb Maintenance Mode włączany przed aktualizacjami, pracami naprawczymi itp.:

esxcli system maintenanceMode set --enable true

Dla ambitnych polecam domyślenie się jak wygląda wyłączanie wspomnianego trybu.

MG

Tagi: komendy, linia poleceń, Linux, VMWare

OpenVAS, GVM na Dockerze

OpenVAS należący do znanego projektu o nazwie GVM zalicza się do zestawu narzędzi typu trzeba mieć dla każdego współczesnego administratora, lub jak ktoś woli devopsa (prawda, że od razu brzmi lepiej?). Czy ktoś chce czy nie, temat cyberbezpieczeństwa stał się na tyle modny/istotny, że trzeba zawsze poważnie podchodzić do swoich zadań z tego zakresu. Aby zatem ustrzec się przed włamaniem najlepiej jest samemu sprawdzać swoje sieci, nawet za pomocą podstawowego zbioru wektorów, pod kątem podatności na ataki. Tak zwane testy penetracyjne (powszechnie określane jako pentesty) są tutaj bardzo pożądanym działaniem. I właśnie wspomniany na początku OpenVAS jest jednym z najlepszych środków dla zebzpieczenia się dzięki sprawdzeniu jake luki może posiadać sieć, którą się opiekujemy.

Istalacja OpenVAS od podstaw jest jak najbardziej możliwa, wymaga jednak umięjętnego poruszania się w środowisku Linuksa, oraz co najmniej średniego stopnia zaawansowania biorąc pod uwagę kompilacje kodu źródłowego. Aby w pełni uruchomić i dostroić pakiet trzeba skonfigurować poprawnie dużą liczbę zależności oraz dodatków, bez których aplikacja nie stanie się pełnowartościowym produktem.

Druga, nie mniej istotna sprawa to aktualizowanie definicji wektorów ataku, które przecież w dzisiejszych czasach zmieniają się dość gwałtownie. Jest to również proces, nad którym trzeba zapanować. Używanie do pentestów OpenVAS z niektualnymi zbiorami podatności mija się po prostu z celem.

Aby przyspieszyć proces wdrażania opisywanego narzędzia można skorzystać z kontenerów Docker. Jest to dobra wiadomość, w szczególności dla niezaawansowanych użytkowników. Niemniej próżno szukać oficjalnego źródła na portalach w rodzaju Docker Hub. Dlatego chciałem się podzielić konfiguracją, z kórej sam korzystam. Jest ona sprawdzona o tyle, że przekonałem się, iż jak na razie jest aktulizowana przez autora. Poza tym, aby pobrać najnowsze wektory wystarczy uruchomić ponownie kontener. W trakcie startu zostaną uruchomione skrypty, które zadbają o sprawdzenie stanu definicji i w przypadku konieczności zmiany wersji na nowszą wykonają to za nas.

Co zatem należy zrobić? Zakładając, że na przykład mamy już zainstalowany Docker wraz z docker-compose, oraz dla wygody środowisko graficzne do zarządzania kontenerami Portainer, przechodzimy do zakładki Stacks i budujemy nową konfigurację korzystając z poniższego kodu.

version: "3"
services:
openvas:
ports:
- "8080:9392"
environment:
- "PASSWORD=admin"
- "USERNAME=admin"
- "RELAYHOST=172.17.0.1"
- "SMTPPORT=25"
- "REDISDBS=512" # number of Redis DBs to use
- "QUIET=false" # dump feed sync noise to /dev/null
- "NEWDB=false" # only use this for creating a blank DB
- "SKIPSYNC=false" # Skips the feed sync on startup.
- "RESTORE=false" # This probably not be used from compose… see docs.
- "DEBUG=false" # This will cause the container to stop and not actually start gvmd
- "HTTPS=false" # wether to use HTTPS or not
volumes:
- "openvas:/data"
container_name: openvas
image: immauss/openvas
volumes:
openvas:

Więcej szczegółów można znaleźć na stronie https://github.com/immauss/openvas . Miłej zabawy.

MG

Tagi: Docker, komendy, konfiguracja, Linux

VMware, converter, 97% error

Wirtualizacja w wydaniu VMware jest bardzo popularnym rozwiązaniem. Żeby uruchomić pełnoprawny serwer z maszynami wirtualnymi wystarczy średniej klasy sprzęt oraz konto na platformie VMware. Oprogramowanie ESXi (co prawda w ograniczeniami, które dotyczą przede wszystkim limitu rdzeni na jednostkę) jest dostępne jako wersja ewaluacyjna do pobrania. Wygodny interfejs webowy pozwala nawet niezaawansowanemu użytkownikowi na zarządzanie swoim środowiskiem.

Gdy przekonamy się do zalet wirtualizacji może pojawić się konieczność przeniesienia fizycznych serwerów do Vmware. Również w tym przypadku firma udostępnia narzędzie Vmware Standalone Converter (VCS), aby za jego pomocą automatycznie przeprowadzić proces migracji. I tutaj zaczynają się schody. Wspomniana aplikacja, która adresowana jest dla systemów Windows jest po prostu przestarzała. Owszem obsługuje większość systemów operacyjnych, ale nie wszystkie do końca prawidłowo.

Pierwsze kłopoty pojawiają się w momencie konwersji systemów linuksowych z macierzą RAID zrealizowaną programowo. Ze względu na ogólnodostępne informacje na ten temat nie skupie się dalej na tym problemie. Następne w przypadku nowszych wersji Linuksów. W artykule opisuje proces na przykładzie Debiana w wersji 10. VSC nie potrafi sobie poradzić z przeniesieniem GRUB, czyli zainstalowaniem bootloadera. Konwersja zatrzymuje się na 97% i pojawia się komunikat o błędzie.

Jest on mylący ponieważ sugeruje nieukończenie konwersji, która w rzeczywistości dobiegła do końca etapu klonowania danych i jedyną operacją niesfinalizowaną jest wspomniana wcześniej instalacja GRUB.

Możemy (a raczej powinniśmy) ręcznie naprawić sytuację. Na hoście maszyn wirtualnych wyszukujemy zduplikowany serwer (w tym przypadku jego kopie). Następnie edytujemy jego ustawienia i wskazujemy obraz ISO z wersją instalacyjną Debian 10 jako źródło dla danych w napędzie DVD. Trzeba jednak pamiętać o włączeniu opóźnienia w bootowaniu systemu (opcja ukryta w menu Edit) tak aby możliwe było wyświetlenie menu wyboru źródła systemu za pomocą klawisza ESC podczas uruchamiania maszyny.

Po starcie systemu z płyty instalacyjnej wybieramy Rescue Mode. Następnie powinniśmy uruchomić konsolę tekstową i wywołać polecenie blkid. Jest to konieczne, gdyż musimy poznać nowe identyfikatory dysków twardych UUID, które zmieniają się podczas klonowania.

Następny krok to pracowita edycja pliku /etc/fstab, aby poprawić identyfikatory, o których wspomniałem powyżej. Możemy to zrobić za pomocą edytora vi lub nano, w zależności od tego, który będzie dostępny.

W ostatnim kroku korzystamy z dwóch komend, instalując (i naprawiając przy okazji) GRUB:

grub-install /dev/sda
update-grub

W miejsce przykładowej /dev/sda powinniśmy wstawić docelową partycję dla bootloadera (prawdopodobnie w 90% przypadków nie trzeba tego zmieniać).

Ostatnią czynnością będzie ręczne zrestartowanie maszyny wirtualnej – korzystamy z funkcji ESXi. Przy odrobinie szczęścia okaże się, że jednak maszyna została przeniesiona prawidłowo.

MG

Tagi: Debian, Linux, serwer, VMWare, wirtualizacja

Portainer – aktualizacja

Portainer to jedna z najlepiej znanych i powszechnie stosowanych platform do wygodnego zarządzania kontenerami Dockera. Zamiast koncentrować się na zapamiętaniu komend linii poleceń możemy przez interfejs graficzny wyklikać praktycznie wszystko. Oczywiście, że zawsze znajdą się zwolennicy „czarnego ekranu”, przyznam że rówież często korzystam z tej metody, ale przy dużej liczbie zarządzanych kontenerów wygodniej jest po prostu skorzystać z przeglądarki.

Od czasu do czasu, w dolnym lewym rogu ekranu powitalnego Portainera pojawia się jednak informacja o dostępności nowej wersji. I w tym przypadku, nie ma już wyjścia, musimy posilić się bezpośrednio terminalem tekstowym. Poniżej zamieściłem podstawowe komendy, których użycie pozwoli zaktualizować Portainer. Oczywiście założyłem, że środowiskiem uruchomieniowym naszego Dockera jest Linux. W moim przypadku, bez wyjątku to któraś wersja pochodna z gałęzi Dabiana. Należy również wspomnieć, że jak będziemy już mieć najnowszy Portainer, to z jego poziomu możemy aktualizować inne kontenery, nie używając linii poleceń.

Zaczynamy od wpisania dwóch poleceń aby zatrzymać i usunąć kontener Portainera:

docker stop portainer
docker rm portainer

Następnie usuwamy obraz Portainera z lokalnego repozytorium:

docker images
docker rmi [IMAGE ID]

Pierwsze polecenie pokaże nam listę wszystkich obrazów. W kolejnym staramy się usunąć wybrany poprzez wskazanie jego ID.

Teraz czas na pobranie najnowszego obrazu Poratinera:

docker pull portainer/portainer-ce

I wreszcie możemy zainstalować nową wersję platformy:

docker run -d -p 8000:8000 -p 9000:9000 —name=portainer /
—restart=always -v /var/run/docker.sock:/var/run/docker.sock /
-v portainer_data:/data portainer/portainer-ce

Dobrze jest pamiętać aby nie zmieniać wartości parametru portainer_data, dzięki czemu nie stracimy ustawień konfiguracyjnych pomiędzy kolejnymi aktualizacjami.

I to wszystko. Teraz można przystąpić do testowania.

MG

Tagi: Docker, linia poleceń, Linux, Portainer, wirtualizacja

Automatyczne rozsyłanie e-maili – Swaks

Automatyczne rozsyłanie e-maili (np. za pomocą opisanego poniżej programu Swaks) z informacjami technicznymi jest chlebem powszednim każdego właściciela serwera. Ponieważ nadzorowanie za pomocą codziennego logowania się i ręcznego przeglądania dzienników systemowych bywa dość żmudną czynnością, stąd każda automatyzacja jest w cenie. Generalnie w systemach linuksowych lokalny serwer SMTP jest na wyposażeniu standardowym. Wysłanie wiadomości z jego pomocą nie stanowi problemu, o ile stosujemy lokalnego klienta. Zresztą wiele usług systemowych właśnie w ten sposób komunikuje się z użytkownikiem. Niemniej czasami potrzebujemy wysłać email na zewnętrzny adres. Poza tym nie zawsze chcemy konfigurować w pełni MTA. Być może łatwiej byłoby użyć jakiegoś kompaktowego narzędzia, które pozwoli z linii poleceń, wygodnie i w prosty sposób przesłać pełnowartościowy email.

Aplikacja Swaks (Swiss Army Knife for SMTP) jest maksymalnie uproszczonym, ale bardzo przydatnym narzędziem wiersza poleceń. Jest ono przede wszystkim używane do testowania serwera SMTP, ale również do wysyłania poczty bezpośrednio “z palca” oraz za pomocą skryptów czy systemowej usługi crone.

Żeby nie zagłębiać się zbytnio w opis wszystkich możliwości Swaks, które zawsze można poznać z pomocą dokumentacji, przejdźmy bezpośrednio do przykładu:

swaks --to odb@mail.org --from "nad@mail.net" /
--server serwer.smtp.net --auth LOGIN --auth-user / 
"nad@poczta.net" --auth-password "P@ssw0rD" / 
-tls --port 587 --header "Subject: [WAZNE] Log systemowy" /
--body /var/log/sys.log

Rozłóżmy powyższą komendę na czynniki pierwsze:

• to – wskazujemy odbiorcę naszej wiadomości,
• from – to adres, który zostać wyświetlony w polu FROM,
• server – serwer SMTP, którego chcesz użyć do wysyłania poczty (np. Gmail),
• auth – rodzaj identyfikacji, jeśli używamy hasła to LOGIN,
• auth-user – nazwa użytkownika na serwerze SMTP,
• auth-password – hasło użytkownika (niestety zapisane jawnym tekstem!),
• tls – włączamy szyfrowanie STARTTLS,
• port – port serwera SMPT, np. 587 czyli Submission,
• header – nagłówek wiadomości, jeśli chcemy dodać temat to użyjemy wyrażenia Subject:,
• body – tutaj może pojawić się tekst lub ścieżka do pliku, który chcemy wczytać.

Celowo pominąłem sposób dodawania załącznika, bo chcę zachęcić do zabawy z narzędziem. Zawsze warto poświęcić 15 minut na testy i przekonać się jak bardzo jest ono wygodne, nawet dla użytkownia z podstawową wiedzą.

MG

Tagi: komendy, linia poleceń, Linux, serwer

Konteneryzacja – error while removing network

Konteneryzacja jest obecnie bardziej modna niż wirtualizacja. Świadomie zaryzykuję takie stwierdzenie choć wiem, że wielu mogłoby się oburzyć. Nie obecnie, tylko od kilku lat, oraz wirtualizacja nadal ma się dobrze. Trzeba jednak przyznać, że lista aplikacji, które zostają zwirtualizowane do formy kontenera np. typu Docker, wydłuża się z każdym rokiem wykładniczo. Dlatego jako fanatyk klasycznej wirtualizacji również musiałem zmierzyć się z tym zagadnieniem. Początki były trudne i nie była to miłość od pierwszego wejrzenia. Jednak z czasem powoli przekonywałem się, chociaż do dzisiaj gnębi mnie myśl o bezpieczeństwie w kontekście aktualizacji gotowych kontenerów dostępnych chociażby przez stronę Docker Hub. Jest to jednak historia na inną opowieść.

Wracając do tematu, skoro przekonałem się do świata kontenerów to zacząłem niemal masowo testować nowe rozwiązania, aplikacje itd. Taki jest los neofity, ale co na to poradzić. Będąc jednocześnie zagorzałym zwolennikiem minimalizmu, wymyśliłem sobie implementację minimalnego serwera w oparciu o Debian Buster (coś w rodzaju bare metal) gdzie jedynym większym softem będzie właśnie paczka docker. W miarę przybywania aplikacji w moim testowym środowisku zacząłem szukać nakładki graficznej do zarządzania. Z pomocą przyszedł pakiet Portainer ze środowiskiem graficznym do zarządzania całą wirtualizacją wraz z prawie jej wszystkimi elementami. Brnąłem dalej. Wiadomo jednak, że im dalej w las tym więcej drzew. Zaczęły się pojawiać problemy. Co gorsza czasami były to w zasadzie dość zasadnicze usterki Dockera. Jedną z nich okazały się hmm… nieścisłości dotyczące definiowania sieci przydzielanych poszczególnym aplikacjom.

Jedną z opcji dostępnych z poziomu Dockera jest tworzenie tzw. macvlan. Jest to sieć kontenerów, które są wystawione poza natowaną warstwą sieciową chronioną przez natywną wirtualizację, co zapewnia oczywiście separowanie aplikacji, a więc odpowiedni poziom bezpieczeństwa, ale uniemożliwia z kolei przydzielanie adresów IP na poziomie równorzędnym z hostem dockera. Czasami potrzebujemy właśnie takiego rozwiązania aby uzyskać efekt podobny do interfejsu typu bridge z klasycznej wirtualizacji (VMware czy KVM). Niestety moim zdaniem obsługa macvlan jest po prostu źle napisana. W wyniku eksperymentowania z sieciami tego typu często dochodzi do sytuacji, w której w systemie pozostają sieci macvlan zachowujące się jak zombie tzn. takie, które do niczego nam się nie przydają (chcieliśmy akurat coś przetestować) a nie można ich usunąć bo otrzymujemy błąd:

“Error response from daemon: error while removing network: configuration network “…. macvlan x.x.x.x” is in use”

W sieci można znaleźć bardzo dużo informacji na ten temat oraz niemal tyle samo propozycji rozwiązania. Ja natomiast chciałem zaproponować jedno z nich, wybrane przeze mnie i myślę, że niezawodne. Zaznaczam od razu, że dotyczy ono hostów typu Linux i wymaga minimalnej znajomości konsoli systemowej. Cały przepis wygląda mniej więcej tak:

• Zaloguj się do swojego hosta za pomocą połączenia SSH.
• Zmień konto na root (o ile już nie zalogowałeś się jako root, ale w tym przypadku poważnie zastanowiłbym się nad zabezpieczeniami Twojego systemu)
• Usuń ręcznie plik local-kv.db

rm /var/lib/docker/network/files/local-kv.db

Tyle w temacie. Rozwiązanie ma tylko taką wadę, że usuwa wszystkie zdefiniowane przez nas sieci ze środowiska konteryzacji. Pozostawia oczywiście tylko te standardowe tj. tworzone na początku instalacji Dockera. Ale porządek na pewno zostanie przywrócony. 🙂

MG

Tagi: Docker, linia poleceń, Linux

Nigdy nie zajrzysz do logów systemowych – porada dla leniwych

Każdy użytkownik systemów z rodziny linuksów w pewnym momencie zaczyna się interesować komunikatami systemowymi. Może się oczywiście zdarzyć, że nigdy nie zajrzysz do logów systemowych, ale jest to raczej mało prawdopodobne. Jeśli zaś jesteś administratorem serwera to czy chcesz czy nie, w terminalu systemowym na pewno zaskoczą Cię nie raz informacje pochodzące od rozmaitych procesów działających w tle. Tak czy inaczej, aby cokolwiek poprawnie zainstalować, a już na pewno skonfigurować, znajomość zawartości katalogu /var/log wydaje się niezbędna.

Oczywiście przeglądanie logów jest czynnością (powiedziałbym) konieczną ale również żmudną. Bywa tak, że nadmiar informacji generowanych przez rozmaite programy staje się przekleństwem. Jest o tyle niebezpieczna sytuacja, że w szumie informacyjnym mogą być ukryte te naprawdę istotne z punktu widzenia np. bezpieczeństwa. Trzeba spojrzeć prawdzie w oczy i z ręką na sercu odpowiedzieć sobie na pytanie czy będzie mi się chciało codziennie pracowicie studiować linijka po linijce pliki z logami, czy może lepiej w jakiś sposób usprawnić to zadanie.

Istnieje kilka dobrych wspomagaczy, czyli narzędzi, które pozwalają parsować logi w locie i kierować do administratora systemu wyłącznie przydatne komunikaty. Aplikacją, z której korzystam na co dzień jest logcheck. Ponieważ mam zwyczaj traktowania poczty elektronicznej jak osobisty notatnik, to właśnie logcheck przesyłający rezultaty skanowania na moją skrzynkę wydaje się być idealnym i dopasowanym rozwiązaniem. Niestety rzeczywistość jest często daleka od ideału. Co prawda nie muszę już ręcznie przeglądać plików, ale tak czy inaczej dziennie otrzymuje od kilkunastu do kilkudziesięciu komunikatów (sic!). Mowa tu o sytuacji kiedy korzystamy z logchecka bez żadnych usprawnień i dodatekowej konfiguracji.

Jak praktycznie każdy program konsolowy również logcheck umożliwia konfigurację do własnych potrzeb. Możliwe jest napisanie własnych filtrów w oparciu o składnie wyrażeń regularnych, które odsieją dla nas automatycznie niepożądaną treść. Tyle, że pisanie wyrażeń regularnych wraz z ich testowaniem na plikach logów systemowych wcale nie jest łatwe i przyjemne. Mogłoby się wydawać, że sytuacja jest bez wyjścia.

Można być jednak zawsze leniwym administratorem i skorzystać z pracy innych (czytaj społeczności Linuksa) i zajrzeć na stronę: https://github.com/ties/logcheck-extrarules. W katalogu ignore.d.server, który jest odpowiednikiem takiego samego zasobu na naszym serwerze znajdziecie wiele zestawów reguł, które są ładnie i logicznie posortowane oraz opisane. W zasadzie wystarczy wyszukać interesujące nas filtry, powiedzmy dla nadmiarowych komunikatów jądra systemu będą to local-kernel, a następnie pobrać do naszego systemu. Jeśli coś nie będzie działać jak trzeba, to zawsze pozostaje ręczne zdobywanie wiedzy i doświadczenia poprzez pisanie wyrażeń regularnych osobiście.

MG

Tagi: Linux, monitoring, serwer

Aktualizacja XSIBackup

XSIBackup jako super wygodne narzędzie do wykonywania kopii zapasowych maszyn wirtualnych VMware sprawuje się bez zarzutu. Pisałem o tym programie wielokrotnie np. tutaj. Wspominałem również, że w połączeniu z VMware vCenter Converter Standalone stanowi szwajcarski scyzoryk na wypadek grubszej awarii tj. gdy musimy bardzo szybko odtworzyć wirtualizację np. z powodu awarii sprzętowej hosta.

W przyrodzie nie ma jednak rozwiązań doskonałych i nawet XSIBackup potrafi spłatać figla. Sytuacja, którą chciałem opisać dotyczy momentu tuż po aktualizacji VMware ESXi, kiedy mamy już powgrywane najnowsze patche a jeszcze nie aktualizowaliśmy naszego programu do kopii. Ja po prostu o tym zapomniałem – do tego stopnia, że nawet przeoczyłem brak nowych raportów email o kopiach zapasowych. A program się zwiesił.

Dość szybko znalazłem opis błędu w Internecie, odpowiedzialny był interpreter, a dokładniej jego niezgodność (w nowej wersji VMware) ze starszą wersją XSIBackup. Stanąłem przed koniecznością zainstalowania nowego wydania… i popełniłem duży błąd. Podążając za rozmaitymi poradnikami z forów użytkowników, gdzie twierdzono, że zasadniczo wystarczy podmienić odpowiednie pliki i wszystko powinno działać, pracowicie skopiowałem co trzeba. Zależało mi głównie na tym aby nie tracić tzw. jobs, czyli zadań kopiowania, które zdążyłem skonfigurować (nie jest to trywialna czynność ze względu na mnogość opcji). Zostawiłem całość bez przetestowania – kolejny błąd, a za dwa dni zadzwonił do mnie zaniepokojony użytkownik z informacją, że serwer nie działa. Chodziło o jdną z maszyn wirtualnych. Okazało się, że nie odpowiada cały host VM 🙁 Była sobota i w tym momencie runęła perspektywa wypoczynku. Po dotarciu na miejsce tzn. do serwerowni, ze zdziwieniem stwierdziłem, że serwer działa bez zarzutu, ale interfejsy sieciowe padły. Rzecz jasna restart całej jednostki pomógł, ale zmobilizowało mnie to do wykonania dwóch czynności, które powinienem zrobić od razu.

Po pierwsze usunąłem całą instalację XSIBackup. Polega to głównie na skasowaniu wszystkich plików i co ważne usunięciu zadań kopiowania na poziomie cron:

rm -rf "/vmfs/volumes/datastore1/xsi-dir"; \ 
chmod 0700 /var/spool/cron/crontabs/root; \ 
sed -i '/-dir\/jobs/d' /var/spool/cron/crontabs/root; \ 
sed -i '/cron-init/d' /etc/rc.local.d/local.sh

Po drugie zainstalowałem od nowa XSIBackup odtwarzając skopiowane wcześniej zadania automatycznego wykonywania kopii. Na szczęście pomogło.

MG

Tagi: ESXi, linia poleceń, Linux, serwer, VMWare