K-NET s.c.

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

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

Problem wyciekania danych

Problem wyciekania danych z naszych komputerów jest jednym z najczęściej omawianych zagadnień przez ostatnie miesiące a nawet lata. Skądinąd wiadomo, że wszyscy wielcy gracze na rynku ogólnie pojętych usług internetowych starają się pozyskiwać wszelkie możliwe informacje niezależnie od tego czy wyrażamy na to zgodę czy nie. A ponieważ nawet Ci, którzy dotychczas nie korzystali z usług rozporoszonych, na przykład w architekturze klient-serwer, opracowali nowe wersje swoich produktów, które po prostu wymagają Internetu pod pozorem chociażby aktualizacji, to praktycznie każdy chce stosować telemetrię. Jest to oczywiście dość łagodne określenie dla ciągłej obserwacji użytkownika, uczenia się jego nawyków itp.

Żeby walczyć z podobnymi praktykami można zastosować kilka różnych podejść. Pierwszym, które wydaje się być dosyć oczywiste jest zainstalowanie odpowiedniej aplikacji. Często funkcje nadzorowania połączeń wychodzących z komputera mają wszelkiej maści programy antywirusowe. Ale uwaga – bywa, że same lubią nas podglądać. Poza tym wiele aplikacji potrafi wykryć działanie tychże i na przykład prosić użytkownika o wyłączenie zapory pod pozorem odmowy świadczenia dalej usługi.

Kolejnym jest zainstalowanie w przeglądarce internetowej odpowiednich dodatków. Dotyczy to oczywiście korzystania z samej przeglądarki i nie zabezpiecza przed innym rodzajem użytkowania. Nie mniej wtyczki takie jak AdBlock czy Ghostery są bardzo popularne. Ponadto producenci samych przeglądarek dodają w ich najnowszych wersjach blokowanie reklam itd. Z drugiej strony czy można im wierzyć do końca? To pytanie retoryczne. Jedno jest pewne – ta metoda również ma wiele wad.

Trzecim rozwiązaniem będzie skorzystanie z połączenia VPN z funkcją blokowania dla wycieku danych z naszych komputerów. Wymaga to najczęściej zastosowania dodatkowej aplikacji, która będzie w stanie wygenerować wspomniane połączenie VPN, za co nierzadko trzeba zapłacić. Tutaj prym wiedzie usługa o nazwie Internet Private Access. Posiada bardzo szerokie możliwości konfiguracji oraz aplikacje w wersji instalacyjnej dla niemalże każdego systemu operacyjnego. Do równie ciekawych rozwiązań, które zdążyły już zdobyć pewną sławę w kręgach deweloperów należy ProtonVPN. Lista dostawców jest naprawdę długa i nietrudno jest wyszukać odpowiedniego dla siebie.

Na sam koniec zostawiłem rozwiązanie, które moim zdaniem jest najlepsze. Jest ono lekkie bo nie wymaga instalowania żadnego dodatkowego oprogramowania. Ciężko jest je wykryć (mam na myśli aplikacje czy systemy korzystające z telemetrii) bo ingeruje w jeden z podstawowych protokółów sieciowych jakim jest DNS. Jest w stanie zmienić zachowanie absolutnie każdego programu, który tylko będzie chciał nawiązać komunikację przez sieć Internet. Co więcej, całkiem prawdopodobne, że przyspieszy oraz poprawi funkcjonowanie naszych końcówek sieciowych, bo znacznie ograniczy niepotrzebny ruch. Mowa oczywiście o serwerze DNS, który będzie miał odpowiednio skonfigurowane reguły rozwiązywania nazw, tak aby po prostu zablokować wszystkie podejrzane odwołania.

W wersji dla leniwych można po prostu skorzystać z bezpłatnego (będzie miał wyłączone niektóre funkcje ale na początek powinno wystarczyć) gotowca. Jest nim na przykład serwis OpenDNS. Przyznam, że korzystałem z niego przez wiele lat z dużym powodzeniem. Po zarejestrowaniu konta użytkownika oraz skonfigurowaniu serwerów DNS, czyli podaniu poniższych wartości w ustawieniach karty sieciowej system startował bez zarzutu.

208.67.222.222
208.67.220.220

W wersji dla zuchwałych trzeba samemu lokalnie przygotować serwer DSN, który będzie mógł obsługiwać ruch sieciowy. Bardzo dobrym rozwiązaniem jest w tym przypadku Pi-hole. Społeczność użytkowników i programistów przygotowała kompletny system, gotowy do użycia „po wypakowaniu z pudełka”. Można go zastosować na mikrokomputerze Raspberry Pi – jest to jeszcze jedno jego doskonałe zastosowanie. Można również, do czego zachęcam, skorzystać z kontenerów Docker i w zasadzie jednym poleceniem postawić cały serwer.

docker-compose up --detach

Szczegółowy opis jak zainstalować całość jest dostępny na GitHubie – https://github.com/pi-hole/docker-pi-hole.

Na zakończenie warto zadać ponownie pytanie – problem wyciekania danych, czy można skutecznie przeciwdziałać? Odpowiedzią niech będzie prosty raport z dnia dzisiejszego dla mojej domowej sieci.

MG

Tagi: Docker, konfiguracja, 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

Czyszczenie dysków twardych na zdalnym serwerze

Czasami zdarza się sytuacja, która zmusza nas do zrównania serwera z ziemią – mam na myśli czyszczenie dysków twardych. Powodów może być wiele, np. zwrot do dostawcy wynajmowanego zdalnego serwera fizycznego itp. Tak czy inaczej lepiej nie oddawać swoich danych. O danych innych użytkowników, ze względu na przepisy RODO, mogę nawet nie wspominać.

Jeśli sprzęt stoi pod ręką to zwykle nie problemu – chociażby ze sformatowaniem dysków. Możemy je nawet wyjąć i zabezpieczyć. Co zrobić jednak kiedy nasze zasoby są zainstalowane w centrum danych a jedyną możliwością jest połączenie zdalne. Nie ma nawet dostępu do konsoli. Wiem, że wielu osobom może wydawać się prawie niemożliwe, ale jednak tak bywa. Nawet w dzisiejszych czasach. Uściślając jedyną metodą dostępu pozostaje terminal SSH.

Po zabezpieczeniu/skopiowaniu danych, o czym musimy zawsze pamiętać, możemy przystąpić do dzieła zniszczenia, chodzi o czyszczenie dysku twardego. Na początek warto wspomnieć, że większość systemów linuksowych w lokalizacji:

/dev/shm

udostępnia dysk RAM. Jest to dobre miejsce na skopiowanie narzędzi, do których nie będziemy mieć dostępu po skasowaniu danych np. ls. Następnie powinniśmy zabezpieczyć dostęp do procesów czyli wykonać następujące komendy:

mkdir /dev/shm/proc
mount -t proc proc /dev/shm/proc

Tak przygotowani przystępujemy do ostatniego nieodwracalnego zestawu kroków.

Najpierw odmontowywujemy wszystkie niepotrzebne partycje. Potem, jeżeli używamy macierzy RAID, to powinniśmy odmontować wszystkie dyski poza bieżącym (de facto należy je wyczyścić oddzielnie). Wreszcie zmieniamy katalog na dysk RAM i wpisujemy:

shred -n2 -z -v /dev/sda

W wyniku działania aplikacji shred usuniemy zawartość dysku sda. Komenda zapisuje losowo bity na /dev/sda, w dwóch pełnych przebiegach (-n2), a następnie wykonuje końcowy przebieg zerami, dzięki czemu dysk wygląda na idealnie czysty (-z). Ostatnia opcja (-v) posłuży do zwiększenia poziomu szczegółowości logów wyświetlanych na ekranie podczas wykonywania polecenia.

MG

Tagi: Debian, komendy, serwer

OpenVAS – testy penetracyjne

W dzisiejszych czasach wykonywanie testów penetracyjnych jest, lub przynajmniej powinno być, elementarzem każdego administratora, który zarządza siecią z serwerami obsługiwanymi przez innych użytkowników. Doświadczenie uczy, że pomysłowość ludzka polegająca m. in. na pozostawianiu niezabezpieczonych usług, skonfigurowanych niepoprawnie aplikacji itp. jest praktycznie nieograniczona. Niestety sieć jest tak bezpieczna jak jej nasłabszy punkt. Dlatego chciałem napisać parę słów o dosyć popularnym i prostym w obsłudze narzędziu jakim jest OpenVAS.

Większość popularnych dystrybucji Linuxa posiada gotowe paczki do instalacji. W Debianie 10 Buster (jak do tej pory ostatnim) nie trzeba nawet wspomagać się dodatkowymi bibliotekami, wystarczy wydać polecenie:

apt-get install openvas -y

Po kilku lub kilkunastu minutach, w zależności od stanu łacza internetowego, cały pakiet zostanie zainstalowany i można przejść do jego konfiguracji:

openvas setup

Aplikacja rozpocznie pobieranie aktualizacji z 3 źródeł – NVT, Cert Data i SCAP Data, tak abyśmy mieli dostęp to świeżego zestawu testów, czyli tak naprawdę np. najnowszych definicji dotyczących exploitów, opisanych zagrożeń itp. Całość trochę potrwa i na koniec zostaniemy poinformowani o sukcesie (mam nadzieję) oraz co najważniejsze wyświetlone zostanie hasło dla administratora usługi. Hasło w zasadzie jest jednorazowe i należy je zmienić od razu po pierwszym zalogowaniu, tym bardziej, że nie jest wygodne do zapamiętania.

OpenVAS jest obsługiwany za pomocą przeglądarki internetowej. Domyślnie skonfigurowany jest tylko dostęp lokalny. Może to stanowić pewne utrudnienie, szczególnie w sytuacji gdy korzystamy z serwera bez środowiska graficznego. Dlatego powinniśmy sprawdzić adres IP swojego serwera:

ip a

Następnie trzeba wedytować 2 pliki konfiguracyjne:

/lib/systemd/system/greenbone-security-assistant.service
/lib/systemd/system/openvas-manager.service

i zmienić adres '127.0.0.1′ na uzyskany adres naszego serwera – w każdym miejscu, w którym występuje.

Na koniec pozostaje uruchomić ponownie usługę OpenVAS:

systemctl daemon-reload 
openvas-stop 
openvas-start

Od tej chwili możemy cieszyć się w pełni funkcjonalnym skanerem sieci do celów testów penetracyjnych. Otwieramy przeglądarkę i podajemy adres:

https://adres_ip_serwera:9392

MG

Tagi: Debian, konfiguracja, linia poleceń, Linux, serwer

Wysoki uptime – jak nie restartować serwera

Być może obecnie nie jest to specjalnie popularne, ale dawno, dawno temu jednym z parametrów świadczących o stabilności serwera i zarazem o zdolnościach jego administratora był tzw. uptime. Żyjemy w czasach gdy aktualizacje systemowe bardzo często wymuszają restart całego systemu. Niestety nie dotyczy to tylko serwerów Windows, co kiedyś było głównie ich domeną, ale również serwerów opartych o jądro Linuxa. Często tego typu działania kończą się wyzerowaniem licznika serwera i wspomniany uptime rozpoczyna zliczanie od początku.

Stare nawyki jednak pozostają na trwałe w pamięci i o ile dla Windowsów przestałem się wogóle przejmować ponownym uruchamianiem systemu, o tyle w przypadku ulubionego Debiana za każdym razem ręka drżała jeśli po aktualizacji pojawiał się komunikat o nowych bibliotekach systemowych czy o zgrozo nowej wersji jądra.

Tak było przez kilkanaście lat. Po prostu uznałem, że tak musi być i za każdym razem wolałem dla świętego spokoju zrestartować system. I nagle w zeszłym tygodniu, przy okazji serii aktualizacji serwerów, pojawiła się myśl, że być może są jakieś narzędzia, które podpowiedzą czy na pewno muszę tracić licznik uptime. Okazało się, że jak najbardziej można sobie pomóc. W końcu to Linux.

Pierwsza metoda jest niezwykle prosta. Po każdej aktualizacji należy sprawdzić czy w określonym miejscu pojawił się plik systemowy o nazwie reboot-required. Wygląda to następująco:

$ ls /var/run/reboot-required

Jeśli otrzymamy wynik pozytywny to oczywiście musimy ponownie uruchomić serwer.

Druga metoda polega na zainstalowaniu narzędzia o nazwie needrestart.

$ apt-get install needrestart

Różnica polega na tym, że w wyniku jego działania np. po ręcznym wywołaniu komendy, otrzymamy pełen raport dotyczący nie tylko zrestartowania systemu ale również usług, które należy uruchomić ze względu na nowe wersje bibliotek systemowych. Dodatkowym bonusem jest fakt, że po każdorazowej aktualizacji needrestart zostanie uruchomiony samoistnie i podpowie co należy zrobić dalej. Czyli prawie jak na Windowsach. 😉

MG

Tagi: Debian, komendy, konfiguracja, serwer

AIDE – wykrywanie zmian w systemie plików

Wiele lat temu miałem wątpliwą przyjemność doświadczyć ataku na jeden z serwerów Apache, którymi się opiekowałem. Zmiany, które skutkowały przejęciem serwera i rozsyłaniem za jego pomocą spamu pojawiały się każdego dnia a ja usiłowałem bezskutecznie walczyć z nimi. Wtedy po raz pierwszy pojawiła się myśl, żeby po prostu podejrzeć co atakujący zmienia w systemie plików, tak aby można było rozszyfrować na czym polega sama metoda włamania. Ostatecznie, szczerze mówiąc, zostałem pokonany i wszystko skończyło się instalacją od początku serwisu, ale poznałem narzędzie detekcji włamiań działające na poziomie systemu plików jakim jest AIDE – Advanced Intrusion Detection Environment.

Wiele lat później ta wiedza i to narzędzie bardzo mi pomogły w powstrzymaniu jednego z ataków na inny serwer w celu uruchomienia koparki kryptowalut. Myślę, że warto jest korzystać z AIDE, w szczególności na serwerach wystawionych na publiczny dostęp. Zatem do dzieła!

Zaczynamy od instalacji pakietu AIDE, po uprzednim zaktualizowaniu systemu:

apt-get update -y && apt-get upgrade -y

apt-get install aide

Następnie wykonujemy kopie zapasową pliku konfiguracyjnego AIDE:

cp /etc/aide/aide.conf /ect/aide/aide.oryg;

Teraz możemy przejść do edycji pliku konfiguracyjnego, aby poprawić/dostosować niektóre jego ustawienia. Możemy skorzystać na przykład z edytora nano.

nano /etc/aide.conf 

W plików tym, na początek, zmieniamy absolutne minimum opcji. Z czasem, po zapoznaniu się z pełnymi możliwościami AIDE możemy pobawić się jego ustawieniami. Trzeba jednak pamiętać, że możemy w ten sposób doprowadzić do przeciążania zasobów serwera ze względu na np. długotrwałą i zbyt szczegółową analizę. Dlatego zaczynamy od absolutnego minimum dla obliczenia sumy kontrolnej:

Checksums = sha512+tiger

I tyle na pierwszy raz wystarczy 🙂 .

Po zapisaniu ustawień możemy zaincjalizować AIDE, co może trochę potrwać w zależności od mocy serwera:

aideinit

Następnie wykonujemy małą sztuczkę upewniając się, że AIDE zadziała z poziomy crona systemowego, czyli:

mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

/etc/cron.daily/aide

cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

I to wszystko. Teraz przy odrobinie szczęścia, tzn. jeżeli wszystko poszło zgodnie z oczekiwaniami, będziemy codziennie otrzymywać raport na skrzynkę root z listą zmian w systemie plików w ciągu ostatnich 24 godzin.

MG

Tagi: Debian, konfiguracja, Linux, serwer

xsibackup – ręczne kopie zapasowe VMware ESXi

Wirtualizacja jest obecnie bardzo modnym i nośnym tematem. Oferta dotycząca rozmaitych wersji maszyn wirtualnych oferowanych w ramach usług dostępnych u dostawców jest olbrzymia. Oprócz możliwości wykupienia takiej usługi – z czego przyznam sam korzystam i mogę polecić np. DigitalOcean – istnieje wiele rozwiązań dla użytkowników końcowych, którzy sami chcą się pobawić w administrowanie. W końcu będzie to zawsze jeszcze jedna ciekawa umiejętność, a jak za chwilę postaram się wyjasnić może przydać się w różnych scenariuszach użycia. Rozwiązania pokroju Oracle Virtualbox, chyba najbardziej popularne i łatwe w utrzymaniu, wprowadzają łagodnie w świat wirtualizacji. Potem z reguły przychodzi kolej na rozwiązania niższego poziomu jak VMware ESXi czy KVM. Mowa tu o korzystaniu z własnych hostów maszyn wirtualnych. Wbrew pozorom nie jest to specjalnie trudne i jeżeli tylko korzystamy ze standardowego sprzętu serwerowego to instalacja np. VMware ESXi jest praktycznie bezbolesna.

W momencie gdy jesteśmy już dumnymi właścicielami małej wirtualnej infrastruktury, nawet jeżeli jest to tylko jeden serwer, możemy rozpocząć budowanie własnej sieci serwerów wirtualnych. Zazwyczaj zaczyna się od jednej jednostki ale apetyt bardzo szybko rośnie w miarę jedzenia i z czasem przybywa nam umiętności, pewności siebie oraz oczywiście nowych węzłów sieciowych. Przenoszenie na platformę wirtualizacyjną serwerów Windows czy Linux jest bardzo łatwe. Naprawdę warto zastanowić się nad tego typu wdrożeniami bo można szybko przekonać się o zaletach rozwiązania. Jednak jak zwykle wraz ze wzrostem apetytu zaczynamy również odkrywać powoli minusy. W moim przypadku był to brak pewnych narzędzi administracyjnych wynikający głównie z korzystania z wersji niekomercyjnej VMware ESXi. Mowa tu o automatycznych kopiach zapasowych maszyn wirtualnych, które byłyby wykonywane w locie, czyli bez zatrzymywania usług.

Krótkie badanie rynku komercyjnych aplikacji do wykonywania kopii zapasowych VMware pokazało, że rozwiązań jest bardzo dużo. Niestety większość ma istotne ograniczenia w wersjach demonstracyjnych. Inne z kolei nie integrują się bezpośrednio z hostem maszyn wirtulanych i wymagają stosowania zewnętrznego komputera z aplikacją. Po jakimś czasie trafiłem w końcu na stronę 33hops.com, gdzie znalazłem ciekawe narzędzie o nazwie xsibackup. Był to strzał w dziesiątke, okazało się bowiem, że istnieje nieodpłatne narzędzie linii poleceń, które pzowala wykonać ręcznie i automatycznie kopie zapasowe.

Na wspomnianej stronie, po podaniu adresu email, możemy pobrać oprogramowanie do instalacji. W wiadomości od producenta otrzymamy również bardzo precyzyjną i szczegółową instrukcję instalacji. Koniec końców cały proces sprowadza się do przygotowania komendy (narzędzia), która pozwoli na zrzucenie ad-hoc kopii maszyn wirtulanych. Ogólnie mówiąc, po zalogowaniu się na konsolę naszego hosta możemy rozpocząć całą zabawę. Poniżej zamieściłem dwa przykłady użycia bazując na własnych doświadczeniach.

Aby sprawdzić poprawność instalacji i wykonać test kopiowania maszyn wirtualnych użyjemy polecenia:

./xsibackup --backup-point=/vmfs/volumes/backup /
--backup-type=running --test-mode=true

Opcja test-mode=true spowoduje, że żadne kopie nie zostaną uruchomione, ale będziemy mogli przetestować poprawność polecenia. Z kolei backup-type=running mówi, że skopiowane mają zostać wszystkie uruchomione maszyny wirtualne – bez ich zatrzymywania (sic!).

Drugim poleceniem jest już komenda służąca wykonania kopii wybranej maszyny:

./xsibackup --backup-point=/vmfs/volumes/backup /
--backup-vms="Nazwa maszyny wirtualnej" /
--backup-type=custom

W tym przypadku warto zwrócić uwagę, że ponieważ wskazujemy, którą maszynę wirtualną chcemy skopiować to należy użyć opcji backup-type=custom.

Mam nadzieję, że te dwa przykładowe polecenia zachęcą zainteresowanych do korzystania i używania kopii zapasowych za pomocą xsibackup. W końcu kopie zapasowe to podstawa i nie trzeba chyba tego nikomu powtarzać 😉 .

MG

Tagi: komendy, kopie zapasowe, Linux, serwer, Windows

Docker, Portainer i kłopoty z OpenProject

Techniki wirtualizacji są obecnie bardzo popularne. Począwszy od tych dostępnych na wyciągnięcie ręki dla każdego użytkownika, mam na myśli VirtualBox, a skończywszy na bardziej rozbudowanych typu VMware ESXi, czy QEMU. Te ostatnie wymagają już środowiska w pełni serwerowego i trochę zaawansowanej technicznie wiedzy (ale bez przesady). Z drugiej strony prężnie rozwija się technologia kontenerów wirtualizacyjnych typu Docker. Stają się one popularne głównie w środowisku programistów (koderów i developerów) bo pozwalają w łatwy sposób instalować całe środowiska z przygotowanych obrazów. Skraca to bardzo czas rozwoju oprogramowania, bo daje do ręki skonfigurowany gotowiec jak np. LAMP czyli Linux, Apache, MySQL, PHP/Python/Perl.

W tym wpisie chciałem się właśnie skupić się na apliakcji Docker. Wynika to głównie stąd, że jakiś czas temu realizowałem projekt polegający na zainstalowaniu całego środowiska developerskiego. Składały się na nie serwer z Debianem oraz 3 kontenery: GitLab, Nextcloud i OpenProject. Można powiedzieć solidne środowisko do pracy dla programistów. Całość została uruchomiona w sieci lokalnej, a każdy z wymienionych kontenerów był dostępny pod swoim własnym adresem IP oraz wewnętrzną nazwą domenową. Przy tej okazji chciałem podzielić się dwoma spostrzeżeniami, dotyczącymi problemów, których zrozumienie i dla których przygotowanie rozwiązania bardzo ułatwiło mi opracowanie rozwiązań. Jeden będzie dosyć ogólny, drugi zaś to przykład debugowania rozwiązania i zaaplikowania specyficznej łaty. Ale po kolei.

Środowiskiem kontenerów Dockera można zarządzać oczywiście za pomocą linii komend. Jednak jako alternatywe polecam gorąco projekt o nazwie Portainer. Instalowany jako jeden z pierwszych kontenerów naszego Dockera pozwoli w dosyć prosty i elegancki sposób zarządzać całością. Zwolenników aplikacji webowych ucieszy na pewno fakt, że jest to po prostu serwer, który udostępnia interfejs przeglądarkowy. Możemy zarządzać praktycznie wszystkimi potrzebnymi modułami w tym: kontenerami, obrazami, wolumenami i sieciami. Możliwości jest dużo więcej i najlepiej jest zainstalować to oprogramowanie samemu, żeby o tym się przekonać. Tym bardziej, że jest to łatwe jak instalacja każdego kontenera w Dockerze 🙂

Drugim problemem, bardziej złożonym, okazała się isntalacja OpenProject. Chciałbym o tym wspomnieć ponieważ jest to bardzo dobry przykład na to, z jakimi problememi można się spotkać używając Dockera. Sama instalacja z oficjalnego, przygotowanego przez autorów obrazu nie nastręcza większych żadnych trudności. Zaraz po uruchomieniu wszysko działa dobrze. Jednak z czasem, gdy będziemy musieli zrestartować cały serwer, a co za tym idzie swoje kontenery również, może się okazać, że OpenProject odmawia posłuszeństwa. Zamiast głównej strony serwisu natkniemy się na informacje o niedostępności. Po przeprowadzeniu wspomnianego na początku debugowania oraz sprawdzeniu stanu samego kontenera (który zachowuje się jak najbardziej poprawnie, czyli uruchamia się i nie zgłasza żadnych błędów) okazało się, że przyczyną jest zatrzymanie się serwera Apache. Niestety ręczne uruchamianie daemona również nie pomaga. Problem jest nieco głębszy i polega na tym, że w trakcie restartu kontenera zdarza się, że nie jest usuwany plik apache2.pid, co z punktu widzenia systemu oznacza, że Apache jak najbardziej działa cały czas (co nie jest prawdą). Rozwiązanie jest dosyć proste. Plik ten należy usunąć ręcznie, czyli:

• z poziomu Portainera (omówionego akapit wcześniej) połączyć się z konsolą,
• usunąć ręcznie plik PID: rm -f /var/run/apache2/apache2.pid,
• uruchomić Apache: /etc/init.d/apache2 start.

Powyższa sztuczka pokazuje, że pomimo iż oficjalne kontenery Dockera zazwyczaj działają bez zarzutu to czasami wymagana jest głębsza wiedza i grzebanie w czeluściach obrazu.

MG

 

Tagi: Docker, komendy, konfiguracja, linia poleceń, serwer, wirtualizacja