Bądź na bieżąco - RSS

Zepsuty pendrive i Macbook

27 grudnia, 2020 | Brak Komentarzy | Kategoria: MacOS, Porady
Pendrive

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

0x80004005 – błąd uruchomienia VirtualBox

2 grudnia, 2020 | Brak Komentarzy | Kategoria: MacOS, Porady
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: , ,

Zewnętrzny numer IP?

31 maja, 2020 | Możliwość komentowania Zewnętrzny numer IP? została wyłączona | Kategoria: Linux, Porady, Windows
Numer IP? Jak uzyskać informacje na ten temat?

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

ESXi – dostrajamy xsibackup

29 marca, 2020 | Brak Komentarzy | Kategoria: Porady
ESXi - narzędzia

WMware ESXi jest naprawdę bardzo przydatnym rozwiązaniem dla wirtualizacji całych systemów. Ponad rok temu pisałem o narzędziu xsibackup, które w wersji nieodpłatnej pozwala wykonywać kopie zapasowe maszyn wirtualnych. Zrobienie kopii to jedna sprawa, czym innym jest przywrócenie z niej systemu. Oczywiście wersja bezpłatna nie ma takiej opcji. Jak sprawdziłem plik z kopią bardzo dobrze nadaje się do wykorzystania przez inne narzędzie,
VMware vCenter Converter Standalone. W ten sposób można cieszyć się całkiem sprawnym systemem zapisywania i odtwarzania maszyn wirtualnych w przypadku awarii. Nawet totalnej katastrofy. Wielu administratorom zapewnia to spokojny sen.

Skoro już mowa o tym czego brakuje w wolnej wersji xsibackup, to tydzień temu natrafiłem na jeszcze jedno ograniczenie. Przy wykonywaniu kopii zapasowych potrzebne jest miejsce nie tylko na samą kopie ale także na operacje związane z buforowaniem i danymi tymczasowymi tworzonymi podczas całego procesu.

Korzystając z przykładu – kupiłem 2 dyski dodatkowe dyski do serwera, tego samego rozmiaru. Pomijając przyczynę nie mogłem dodać ich do macierzy RAID. Postanowiłem na pierwszym utworzyć maszynę wirtualną a na drugi zrzucać codziennie pełną kopię/duplikat tejże. Oczywiście zostawiłem nieco miejsca na pierwszym dysku. Jak się okazało było go zdecydowanie za mało na drugim (tam gdzie docelowo miała być kopia). Zaraz, zaraz możecie zapytać, coś się tutaj nie zgadza. I rzeczywiście za pierwszym razem xsibackup tworzył pierwszą kopię. Jednak zdecydowanie nie chciał wykonać jej po raz drugi jeżeli w tym miejscu znajdowała się kopia z poprzedniego dnia. Niby sprawa jest prosta bo przecież nasuwa się od razu rozwiązanie. Polega ono na usuwaniu za każdym razem istniejącej kopii przed wykonaniem kolejnej. Przecież każdy program do backupów ma coś takiego. Niestety xsibackup w wersji darmowej nie ma!

W tym momencie rozpoczęła się przygoda z ESXi. Usunięcie danych z katalogu w systemie Linux to nic trudnego:

rm -R /scieka_do_katalogu/*

Ponieważ WMware ESXi to tak naprawdę Linux (no może to nie całkiem prawda), można zatem skorzystać właśnie z tej komendy. Należałoby dopisać ją do crona systemowego, tuż przed wykonywaniem kopii zapasowej xsibackup, która już się tam znajduje. I właśnie dostrajanie po swojemu ESXi na tym poziomie jest delikatnie mówiąc kłopotliwe. Dlatego wpadłem na pomysł, żeby zastosować pewną sztuczkę.

xsibackup ma już gotowy zestaw skryptów pozwalający na dodawanie zadań systemowych wg z góry zdefiniowanego harmonogramu. Zadania są umieszczane w jego katalogu instalacyjnym zgodnie z narzuconą konwencją. Pierwsze zadanie znajduje się w pliku:

../xsibackup/jobs/001

Drugie będzie miało nazwę 002 itd. Dlaczego zatem nie dodać w tym miejscu wspomnianej wcześniej komendy – właśnie jako kolejnego zadania? Czyli zawartość pliku 002 powinna wyglądać jak nasza komenda:

„rm -R /sciezka_do_katalogu/*”

Teraz należ jeszcze pamiętać o dodaniu zadanie do crona. Robimy to tak jak w typowym systemie linuksowym, z tym że tutaj edytujemy plik:

../xsibackup/conf/root-crontab

Aby ostatecznie zatwierdzić wszystkie zmiany wywołujemy polecenie

./xsibackup —update-cron

Jeśli nie zostaliśmy ostrzeżeni komunikatami o błędach to znaczy, że udało się. Teraz wystarczy poczekać dzień, dwa aby przekonać się czy nasz backup zadziała poprawnie.

MG

Tagi: ,

Karta SD – formatowanie w Mac OS

29 grudnia, 2019 | Brak Komentarzy | Kategoria: MacOS, Porady
karta SD

Karta SD i jej formatowanie w Mac OS może być źródłem problemów. Sam kilka razy miałem kłopoty. Oczywiście jeśli stosujemy standardowe rozwiązania i mamy kartę sformatowaną dla systemu MS-DOS (FAT), tudzież dla typowego Mac OS Extended (Journaled) to raczej nie napotkamy na żadne przeszkody. Czasami jednak, zwłaszcza gdy zamierzamy testować np. Raspberry Pi, musimy zmierzyć się z innymi systemami plików. I nie chodzi w tym przypadku o zakładanie i konfigurowanie tychże, ale o przygotowanie karty do pracy, czyli usunięcie w pierwszym kroku wszystkich partycji z dostępnej przestrzeni. Niestety, bez tego często nie jesteśmy w stanie korzystać z SD. Wiem, że brzmi to co najmniej dziwnie, ale sam miałem takie problemy.

Jak sprawdziłem najszybszą niezawodną metodą jest skorzystanie z wbudowanych narzędzi systemowych. A więc czas uruchomić terminal. 😉

Jednym z najbardziej pożytecznych i skutecznych narzędzi jest diskutil. Program ten pozwoli nam na wyświetlenie zawartości karty SD:

$ diskutil list

Otrzymamy nazwy urządzeń (np. disk2 lub disk3) z przypisanymi partycjami. Z wyświetlonych informacji można łatwo wywnioskować, które urządzenie to karta SD. Zakładając, że jest np. disk2, możemy przygotować kartę do pracy z Raspberry Pi:

$ diskutil eraseDisk FAT32 RASPBIAN MBRFormat disk2

Na tym jednak nie koniec. Wracając do głównego wątku, możemy również dosłownie wyzerować kartę SD. W tym celu najpierw powinniśmy odmontować urządzenie:

$ diskutil unmountDisk disk2

A potem usunąć jej zawartość:

$ diskutil zeroDisk disk2

Lub inną metodą:

$ diskutil randomDisk disk2

Warto wspomnieć, że opisana komenda sprawdza się również w przypadku pamięci USB, dysków twardych itd. Trzeba jej jednak używać bardzo ostrożnie, i chyba nie muszę tłumaczyć dlaczego.

To tyle w tym ostatnim tegorocznym wpisie.

MG

Tagi: , ,

Czyszczenie dysków twardych na zdalnym serwerze

24 listopada, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Odkurzacz, czyszczenie

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

Telnet w Windows czyli wakacje 2019

25 sierpnia, 2019 | Brak Komentarzy | Kategoria: Porady, Windows
Putty telnet

Po raz pierwszy od 3 miesięcy postanowiłem napisać krótki wakacyjny wpis jako podsumowanie letniego okresu. Chociaż podsumowanie nie będzie tu najlepszym określeniem. Chciałem po prostu zamieścić przynajmniej jeden wpis podczas wakacji 2019 (np. dotyczący popularnej komendy telnet).

Ponieważ nie można tak od razu rzucić się na pracę, tym razem kilka krótkich akapitów o narzędziu telnet. Już ponad 20 lat używam go w codziennej pracy. Powszechnie wiadomo – jest niebezpieczne, powinniśmy go unikać jak tylko można, ale w zasadzie do sprawdzania otwartych portów na zdalnych hostach jest najszybsze. Zapewne większość administratorów używała nie raz polecenia:

telnet host.remote.net 80

żeby sprawdzić czy działa serwer stron www. Komenda ta zadziała nawet jeżeli firewall blokuje pakiety ICMP czyli jeżeli w wyniku:

ping host.remote.net

otrzymamy odpowiedź typu „host jest nieosiągalny”.

W najnowszych wersjach systemów Windows a dotyczy to zarówno stacji roboczych jak i serwerów, ze wspomnianych względów bezpieczeństwa nie ma już komendy telnet. Można ją oczywiście różnymi sposobami doinstalować, jest nawet całkiem sporo poradników typu how-to w sieci. Jednak skoro Microsoft zadecydował, że coś jest niebezpieczne to może znajdzie się alternatywa.

Okazuje się, że wraz z rozwojem środowiska PowerShell, Microsoft dorzuca nam z każdą wersją ciekawe narzędzia. Jednym z nich jest program Test-NetworkConnection. Jeżeli uruchomimy PowerShell w naszym systemie to całkiem spokojnie możemy go wypróbować. A ponieważ parę akapitów wcześniej wspominałem o telnet, to spróbujmy użyć TNC właśnie w taki sposób:

tnc host.remote.net -port 80

Wynikiem będzie raport z ostanią linijką zatytułowaną TcpTestSucceeded. Parametr ten przyjmuje wartości true/false i funkcjonalnie odpowiada staremu dobremu połączeniu za pomocą telnet. TNC ma oczywiście multum innych opcji i serdecznie zachęcam do zapoznania się z dokumentacją.

MG

Tagi: , ,

Wysoki uptime – jak nie restartować serwera

26 maja, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Uptime - system is up to date

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

xsibackup – ręczne kopie zapasowe VMware ESXi

26 stycznia, 2019 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

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.

Zapisz kopie xsibackup na streamerze.

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

Dell R210 – instalacja sterownika sieciowego a Debian 9.6

15 grudnia, 2018 | Brak Komentarzy | Kategoria: Linux, Porady

Rackowe serwery firmy Dell, nawet te z najniższej serii jak Dell PowerEdge R210 II, wyśmienicie nadają się do tworzenia serwisów internetowych. Mam na myśli usługi takie jak WWW czy FTP. Nie są to super wydajne maszyny do obsługi milionów zgłoszeń w ciągu godziny, ale jako hosty dla małych i średnich przedsiębiorstw jak najbardziej znajdą zastosowanie.

Dell R210 instalacja Debiana

Niedawno miałem okazję przygotowywać taki komputer instalując ostatnią wersję Linuxa – Debian Stretch w wersji 9.6. Ponieważ bardzo lubię prostotę i minimalizm dlatego korzystam zazwyczaj z instalacji w wersji sieciowej, tak aby nie zaśmiecać systemu operacyjnego zbędnymi pakietami. Jak nazwa wskazuje aby wszystko udało się bez problemu potrzebna jest sieć, a w zasadzie działająca karta sieciowa, czyli prawidłowo zainstalowany sterownik. Pomimo iż Dell w serwerach R210 raczej na pewno korzysta ze standardowych rozwiązań – czytaj popularnych kart sieciowych (zbudowanych w oparciu o rozpowszechnione chipsety), to jak się okazuje społeczność Debiana tak bardzo dba o używanie otwartych sterowników, że nie zawsze wychodzi to użytkownikom na dobre.

W opisywanym przypadku serwer wyposażony jest w kartę Broadcom NetXtremeII z dwoma interfejsami sieciowymi. Instalacja pozornie przebiega bez problemów. Karty sieciowe są wykrywane poprawnie. Debian korzysta z wbudowanego sterownika (w poprzednich wersjach trzeba było dodawać zenętrzny zamknięty pakiet oprogramowania). Instalator przechodzi do automatycznej konfiguracji przez DHCP i… naszym oczom ukazuje się komunikat o błędzie. Wygląda to tak jakby winne było wszystko, włącznie z serwerem DHCP, tylko nie instalator Debiana. A prawda jest zupełnie inna.

Okazuje się, że kod sterownika dołączonego standardowo do instalatora zawiera błędy. Karta sieciowa działa, ale nie do końca. W tej sytuacji trzeba wspomóc się kilkoma sztuczkami i dodać ręcznie właściwy sterownik.

  • Po pierwsze pobieramy właściwy (zamknięty) pakiet ze strony https://packages.debian.org/stretch/firmware-bnx2.
  • Następnie za pomocą pendrive’a USB przenosimy go na przygotowywany serwer:
    • uruchamiamy instalator Debiana w wersji tekstowej
    • przechodzimy przez pierwsze kroki instalacji pamiętając, że zanim instalator zacznie wykrywać sprzęt musimy wgrać zamknięty sterownik z USB
    • gdy instalator zatrzyma się na jednym z pytań konfiguracyjnych wciskamy ALT+F2 przechodząc do konsoli tekstowej
    • tworzymy tymczasowy punkt montowania i montujemy pendrive
~$ mkdir /tmp/driver
~$ mount /dev/sda1 /tmp/driver
  • Kolejnym krokiem będzie instalacja właściwego sterownika
~$ apt-get install /tmp/driver/firmware-bnx2_xxx-x_all.deb
  • Ostatnią czynnością jest wciśnięcie kombinacji ALT+F1 co pozwoli wrócic do okienkowej wersji instalatora
  • Tym razem podczas wykrywania sprzętu zostanie zainstalowany odpowiednie oprogramowanie

Dalej wykonujemy standardowe czynności, zgodnie z typową instalacją, ciesząc się działającym połączeniem sieciowym.

MG

Tagi: , , , ,