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

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

Homebrew i problemy z unrar

Jeśli jesteś użytkownikiem MacOS to bardzo prawdopodobne, że już słyszałeś o aplikacji Homebrew. Ten system dystrybucji oprogramowania zastępuje dobrze znane rozwiązania konsolowe z systemów linuksowych. Pozwala dbać o aktualizacje, czyścić system z niepotrzebnych pozostałości po instalacjach itd. W zasadzie można powiedzieć, że dla kogoś kto jest przyzwyczajony do repozytoriów oprogramowania stanowi swoiste narzędzie typu must have dla fanów Apple.

Biorąc pod uwagę bogactwo oprogramowania, które trudno znaleźć w oficjalnych kanałach dystrybucji MacOS Homebrew na pewno jest alternatywą dla osób instalujących takie perełki jak np. Midnight Commander czy ffmpeg. Zazwyczaj instalacja takich aplikacji nie stanowi dla niego większych problemów bo sprowadza się do wpisania jednej linijki z komendą w shellu systemowym.

W codziennej pracy z systemem nieodzowne jest narzędzie to archiwizacji plików. W pracy z MacOS dostępnych jest wiele programów spełniających dobrze te funkcje dla większości otwartych algorytmów jak np. Keka. Co jednak jeżeli otrzymamy pliki spakowane za pomocą RAR. Czy szukać płatnej alternatywy dla jabłuszka? A może po prostu zainstalować unrar za pomocą Homebrew? To ostatnie rozwiązanie powinno wystarczyć, aby okazyjnie poradzić sobie z takim problemem. I rzeczywiście do niedawna wystarczało, bo wspomniany unrar został usunięty z oficjalnych repozytoriów Homebrew.

Aby zaradzić przedstawionym powyżej problemom wystarczy jednak skorzystać z prostej metody korzystając z dodatkowych kanałów dystrybucji. W tym celu używając shella systemowego wpisujemy polecenie:

brew install carlocab/personal/unrar

W ten prosty sposób zainstalujemy unrar i zaoszczędzimy trochę pieniędzy.

MG

Tagi: aplikacje, linia poleceń, macos

Zepsuty pendrive i Macbook

Pendrive może zostać zepsuty. Wielokrotnie, jako użytkownikowi Macbooka, zdarzało mi się to zrobić. Działający bez zarzutu przestawał być rozpoznawany przez system. Zdarzało się to po takich operacjach jak formatowanie czy wgrywanie obrazu ISO np. z najnowszą wersją Raspberry Pi OS. Czy to oznacza, że pendrive jest bezpowrotnie uszkodzony? Muszę przyznać, że w 100% przypadków nie. Zazwyczaj nie pomagały żadne wbudowane graficzne narzędzia dla mac OS. Jednak wcale nie oznaczało to, że inne systemy jak Linux czy Windows nie potrafiły naprawić i poprawnie sformatować ponownie pendrive’a. W zasadzie zawsze chodziło o błędy tablicy partycji. No właśnie, czy mac OS jest na tyle kaleki, że trzeba szukać komputera z Windows? Jak poradzić sobie z tak prostym w zasadzie wyzwaniem?

Na szczęście zawsze można skorzystać z poleceń konsolowych i trików dobrze znanych ze wszytskich platform unixo-podobnych. Wiem, że być może nie jest to ładny i dopracowany interfejs graficzny użytkownia, ale zawsze działa niezawodnie. Zatem do dzieła!

Po pierwsze podłączamy kartę SD, dysk twardy lub inne urządzenie. Potem wydajemy polecenie, aby zobaczyć, jako które urządzenie /dev/diskN system zamontował nasz pendrive:

diskutil list

Następnie musimy odmontować dysk, gdzie N jest numerem dysku z poprzedniego polecenia:

diskutil unmountDisk /dev/diskN

Po trzecie przechodzimy do sedna i wykonujemy polecenie dd jako superuser dla dysku, dla którego N jest numerem z pierwszego kroku.

sudo dd if=/dev/urandom of=/dev/diskN bs=1000000

Spowoduje to nadpisanie wszystkich partycji, rekordów MBR i danych. Trzeba pamiętać, że wszytsko może trochę potrwać w zależności od rozmiaru dysku. Niestety nie ma wskaźnika postępu. Warto jednak poczekać i odzyskać prawie utracony pendrive.

MG

Tagi: komendy, Mac OS

0x80004005 – błąd uruchomienia VirtualBox

Wirtualizacja jest obecnie jednym z najczęściej stosowanych rozwiązań zarówno na platformach serwerowych jaki i na komputerach osobistych. Pozwala przygotować środowisko testowe dla programisty. Pozwala uruchomić aplikacje napisane dla innych systemów operacyjnych niż ten, który jest naszym głównym. Zastosowań i pomysłów jest wiele. W szczególności jeśli jesteś właścicielem MacBooka Apple to prawie na pewno chociaż raz zastanawiałeś się jak uruchomić aplikację dla Windows. I nie piszę tu tylko o grach ale również o całkiem sporej rzeszy programów biurowych. Tego typu rozważania prowadzą wprost do produktów takich jak VMware Workstation lub VirtualBox – celowo pomijam programy płatne, takie rownież się znajdą dla macOS.

Z powodu przyzwyczajenia od lat korzystam z VirtualBoxa. Nie jest być może najbardziej wydajny, jak również nie zapewnia pełnego wsparcia sprzętowego, ale jako dobrze znany ma dużą społeczność użytkowników, więc można liczyć prawie zawsze na pomoc. Poza tym jego instalacja dla macOS jest banalnie prosta, a w sieci można znaleźć gotowe do użytku obrazy z Windows. Można również skorzystać z poradników typu jak przygotować sobie Windowsy bez ponoszenia kosztów i pozostać legalnym użytkownikiem – tak przynajmniej twierdzą ich autorzy.

Niestety tak jak często w życiu bywa nawet najbardziej doskonałe rozwiązania potrafią zawodzić. Tak właśnie się stało z moim VirtualBoxem po aktualizacji MacBooka do systemu macOS Big Sur wersja 11. Niby wszystko działało poprawnie i VirtualBox uruchomił się bez zarzutu, ale żadna z maszyn wirtualnych nie chciała już wystartować. Na ekranie pojawiał się komunikat: „The virtual machine 'XXX’ has terminated unexpectedly during startup with exit code 1 (0x1).” Szczegóły błędu są mało czytelne, szczególnie w kontekście wyszukania i dopasowania informacji w Inetrnecie:

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: MachineWrap

Rzecz jasna jeśli zaczniemy przeglądać różne fora – również te poświęcone systemom od Apple – to spostrzeżemy, że porad jak zapobiegać takim wyjątkom jest cała masa. Ja zaś tradycyjnie chciałbym się skupić na na kilku prostych krokach, które przywracają pełną funkcjonalność VirtualBox. Przynajmnie do czasu kiedy ukaże się kolejna wersja tego oprogramowania.

Po pierwsze należy uruchomić MacBooka w trybie Recovery – przy starcie wybieramy kombinację klawiszy cmd+R. Ten krok może trwać dość długo jeżeli konieczne będzie pobranie obrazu systemu z serwerów Apple. Gdy znajdziemy się już w trybie awryjnym to wystarczy uruchomić terminal i wydać dwa polecenia:

csrutil clear
reboot

Po ponownym uruchomieniu komputera działamy dalej. Po pierwsze pobieramy ze strony producenta najnowszą wersję VirtualBoxa oraz pakiet VirtualBox Extension Pack. Po drugie po zamontowaniu obrazu instalacyjnego najpierw usuwamy aktualną wersję za pomocą skryptu VirtualBox_Uninstall.tool. Ostatecznie zaś instalujemy ponownie aplikację oraz pakiet rozszerzeń.

Mam nadzieję, że pomogłem. 🙂

MG

Tagi: komendy, konfiguracja, Mac OS

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

lovemyiot – pierwsze kroki w IoT

Czym jest IoT (ang. Internet of Things – Internet Rzeczy, stąd lovemyiot o czym za chwilę) nie trzeba tłumaczyć. Przynajmniej większości użytkowników sieci. Hasło stało się tak popularne, że nietrudno jest znaleźć w swoim otoczeniu, w pracy lub w domu urządzenie, które może mieć naklejkę z tym terminem. Niemniej trzeba jasno powiedzieć, że IoT to nie tylko inteligentna pralka czy lodówka, która łączy się z Internetem. Po dwuletnich doświadczeniachz z zagadnieniem mogę napisać, że jest to raczej filozofia komunikacji niż konkretne rozwiązanie albo technologia. Wiem, że brzmi to bardzo górnolotnie, ale trafnie oddaje obecny stan rzeczy.

Z IoT łączy się multum rozwiązań. Największy producenci z sektora IT postawili sobie za cel promowanie „nowych” produktów pod hasłem Internetu Rzeczy. Piszę o tym nie bez pewnej złośliwości bowiem sam spotkałem się z przypadkami, gdzie urządzenie sprzedawane do tej pory jako np. termometr IP do serwerowni stało się nagle węzłem IoT. I bardzo dobrze, jeśli założymy, że mamy właśnie do czynienia z filozofią.

Dając się ponieść zmianom postanwiliśmy wraz z kilkoma kolegami z branży zainteresować się IoT od strony komunikacji bezprzewodowej. Na samym początku odrzuciliśmy założenie o węzłach IoT posiadających niewyczerpane zasoby energetyczne i obliczeniowe, skłaniając się w stronę telemetrii (kolejny popularny termin) a więc małych węzełków-czujników z zasilaniem bateryjnym, których ilość idzie w setki albo nawet w tysiące. Bazując na takich podstawach skierowaliśmy się w stronę sieci LPWAN (ang. Low Power Wide Area Network) i dalej w konsekwencji w stronę technologii LoRa (ang. Long Range) oraz sieci LoRaWAN. Tak powstała dziedzina naszej działalności.

Kim jesteśmy? Obecnie jesteśmy nieformalnym stowarzyszeniem o nazwie lovemyiot, które ma zostać przekształcone w fundację wspierającą intensywny rozwój IoT w Polsce, uwzględniając w szczególności tematykę, o której wspomniałem w poprzednim akapicie. Zachęcam do śledzenia postępów działalności na stronach Facebook i Twitter:

Tweets by lovemyiot

MG@lovemyiot

Tagi: IoT, komunikacja globalna

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

Zewnętrzny numer IP?

Numer IP – bardzo często bywa tak, że z jakichś powodów chcielibyśmy uzyskać informację na ten temat (zwłaszcza jeśli chodzi o zewnętrzny numer IP). Jak zauważyłem problem ten dotyczy nie tylko sytuacji, w której po prostu sprawdzamy czy operator przydzielił nam właściwy adres IP, ale również coraz częściej jeśli chcemy np. sprawdzić czy zadziałało połączenie prywatne VPN. Zauważyłem, że powoli stają się one standardem (i bardzo dobrze), warto zatem czasami upewnić się, że nasz ruch przechodzi przez odpowiedni router.

Do tej pory można to było zrobić na kilka, mniej lub bardziej eleganckich sposobów. Dla mniej wprawnych zawsze pozostaje np. serwis https://www.whatismyip.com. Ta metoda wymaga jednak posiadania interfejsu graficznego czyli GUI. A jak zrobić to samo na serwerze, który posiada tylko czystą konsolę tekstową?

Tutaj również mamy do dyspozycji wiele metod. Szczególnie jeżeli używamy mojego ulubionego rozwiązania czyli Linuxa. Od lat korzystałem w tym celu z dobrze znanego polecenia wget, które pozwala na sparsowanie wyjścia i tą nieco pokrętną metodą uzyskanie odpowiedzi na pytanie postawione w tytule artykułu:

/usr/local/bin/wget -qO - http://ipinfo.io/ip

Świat idzie jednak do przodu (i bardzo dobrze). wget powoli jest zastępowany przez nowe polecenie (a w zasadzie rozbudowane narzędzie) czyli curl. W takim wydaniu uzyskanie informacji jaki jest zewnętrzny numer IP jest jeszcze prostsze:

curl http://icanhazip.com

I o to przecież wszystkim chodzi 🙂

MG

Tagi: komendy, konfiguracja, linia poleceń, Linux