Bądź na bieżąco - RSS

Czyszczenie dysków twardych na zdalnym serwerze

Listopad 24th, 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: , ,

OpenVAS – testy penetracyjne

Wrzesień 29th, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
OpenVAS

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

Wysoki uptime – jak nie restartować serwera

Maj 26th, 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: , , ,

AIDE – wykrywanie zmian w systemie plików

Marzec 31st, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
AIDE

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

xsibackup – ręczne kopie zapasowe VMware ESXi

Styczeń 26th, 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: , , , ,

Docker, Portainer i kłopoty z OpenProject

Wrzesień 15th, 2018 | Brak Komentarzy | Kategoria: Felieton, Linux, Porady

Docker

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

Aktualizacja hosta ESXi

Sierpień 18th, 2018 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

VMware ESXiWirtualizacja jest obecnie praktycznie standardem. Jest powszechnie dostępna i łatwo można samemu przygotować własny host maszyn wirtualnych. Od jakiegoś czasu testuje aktualnie kilka instalacji VMware ESXi i muszę przyznać, że jestem zaskoczony wygodą obsługi oraz jak dotąd (odpukać) bezawaryjną pracą. Instalacja jest dosyć łatwa pod warunkiem, że przygotujemy się pod kątem sprzętu. Nie każdy zostanie wykryty przez instalator, ale metodą prób i błedów a także przy wsparciu forów technicznych można rozwiązać większość problemów. Potem jest już z górki. Do czasu. Jak zwykle po jakimś czasie powinniśmy pomyśleć o kwestiach bezpieczeństwa, a co się z tym wiąże aktualizacji naszego hosta.

Jeżeli podobnie jak ja używasz wersji ewaluacyjnej ESXi to znaczy, że najprawdopodobniej korzystasz z trybu standalone server, czyli posiadasz tylko jeden host maszyn wirtulanych. Instalacja tego typu wyróżnia się brakiem wygodnej czytaj graficznej obsługi aktualizacji. Pełna instalacja zarezerwowana jest dla dużych farm hostów, a tak naprawdę trzeba zapłacić za oprogramowanie zarządzające hostami, co na jedno wychodzi. W tym przypadku trzeba sobie radzić za pomocą konsoli tekstowej.  Ale po kolei…

Najpierw należy zalogować się na nasz host używając po prostu przeglądarki internetowej. Z poziomu graficznej konsoli zarządzania trzeba uruchomić usługę SSH. Nie jest ona domyślnie włączona – dla bezpieczeństwa. Wybieramy zatem opcję Manage z okienka Navigator po lewej stronie i w okienku po prawej stronie przechodzimy do zakładki Services. Uruchamiamy usługę TSM-SSH (po zakończeniu aktualizacji warto ją wyłączyć ponownie). Od tej pory możemy połączyć się za pomocą SSH do naszego hosta.

Zaczynamy od sprawdzenia wersji poleceniem:

~ # esxcli system version get
Product: VMware ESXi
Version: 6.7.0
Build: Releasebuild-469512
Update: 0
Patch: 0

Następnie udajemy się na stronę z aktualizacjami dla VMware ESXi i pobieramy właściwą dla naszego systemu. Warto zauważyć, że aktualizacje kumulują się, więc nie ma potrzeby wgrywania wszystkich – wystarczy ostatnia. Dodam, że na pewno trzeba wgrać oznaczone etykietką Critical, reszta według uznania.

Przełączamy host ESXi w tryb Maintenance (za pomocą przeglądarki i strony zarządzającej) i możemy przystąpić do działania. Rozpoczynamy od wyświetlenia listy profili dostępnych w naszym patchu:

~ # esxcli software sources profile list --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip
Name Vendor Acceptance Level
-------------------------------- ------------ ----------------
ESXi-6.7.0-20171002001-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-standard VMware, Inc. PartnerSupported
ESXi-6.7.0-20171001001s-no-tools VMware, Inc. PartnerSupported
ESXi-6.7.0-20171002001-no-tools VMware, Inc. PartnerSupported

Najbezpieczniej jest skorzystać z profilu standardowego, a więc ESXi-6.7.0-20171002001-standard. Jest to zazwyczaj pierwszy dostępny profil z listy. Nim w następnym kroku przystąpimy do aktualizacji serwera, powinniśmy najpierw sprawdzić jaki będzie wynik tej operacji. Z pomocą przychodzi opcja –dry-run. Wpisujemy plecenie:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--dry-run --profile=ESXi-6.7.0-20131002001-standard
Update Result
Message: Dryrun only, host not changed. The following \
installers will be applied: [BootBankInstaller]
Reboot Required: true
VIBs Installed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.1.11.623860, \
VMware_bootbank_esx-base_5.0.0-3.41.1311175, \
VMware_bootbank_esx-tboot_5.0.0-2.26.914586, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.2.26.914586, \
VMware_bootbank_misc-drivers_5.0.0-3.41.1311175, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.7.515841, \ 
VIBs Removed: 
VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.500.0.0.469512, \ 
VMware_bootbank_esx-base_5.0.0-0.0.469512, \
VMware_bootbank_esx-tboot_5.0.0-0.0.469512, \
VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.0.0.469512, \
VMware_bootbank_misc-drivers_5.0.0-0.0.469512, \
VMware_bootbank_net-be2net_4.0.88.0-1vmw.500.0.0.469512,

Jeśli nie otrzymaliśmy żadnych komunikatów o błedach możemy śmiało przystąpić do właściwej aktualizacji. Tym razem korzystamy z komendy:

~ # esxcli software profile update --depot=/vmfs/volumes/ \
datastore1/patch/update-from-esxi6.7-5.0_update03.zip \
--profile=ESXi-6.7.0-20131002001-standard 
Update Result
Message: The update completed successfully, but the 
system needs to be rebooted for the changes to be effective. \
Reboot Required: true

Na sam koniec nie pozostaje nic innego jak uruchomić ponownie serwer VMware ESXi (skoro sam tego zażądał):

~ # reboot

Po starcie systemu wyłączamy tryb Maintenance i voilá! Prawda, że proste 😉

MG

Tagi: , , , , ,

Telnet – instalacja na Windows Server 2016

Marzec 17th, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

TelnetŚrodowisko systemów serwerowych Microsoft zmienia się bardzo dynamicznie. Nie ma co ukrywać, że konkurencja rozwija się bardzo szybko i pomimo, że mogłoby wydawać się, iż nic nie zagrozi dominacji serwerów Windows w segmencie małych i średnich firm wykorzystujących rozwiązania oparte o MS SQL, to sam Microsoft wprowadza modyfikacje podążające za najnowszymi trendami. Nie ukrywam, że na przykład bardzo mnie cieszy współpraca z Canonical i migracja części narzędzi terminalowych wprost z Linuxa. Bo właśnie o terminal tutaj chodzi, a będąc bardziej precyzyjnym o wygodę z jego korzystania (czyli np. poleceń telnet, ftp itd.). Narzędzia interfejsu graficznego mają swoje zalety, w szczególności dla początkującego użytkownika, jednak jeśli ktoś przebrnie przez początkowe trudności to zazwyczaj docenia mocno wygodę korzystania z trybu tekstowego.

W dzisiejszym wpisie chciałem pokazać jak zainstalować narzędzia Windows 2016 Server za pomocą 3 metod. Jak można się domyślić z poprzedniego akapitu skupię się raczej na terminalu niż na okienkach konfiguracyjnych. Za przykład posłuży nam program telnet.

Po pierwsze warto sprawdzić czy przypadkiem telnet nie został już zainstalowany w systemie. Można sprawdzić to w bardzo prosty sposób. Otwieramy terminal tekstowy i wpisujemy polecenie:

C:\>telnet google.com 80
 'telnet' is not recognized as an internal or external command, →
 → operable program or batch file.
C:\>

Powyższy komunikat świadczy, że należy włączyć narzędzie na poziomie serwera, czyli po prostu zainstalować aplikację.

Tereaz możemy przejść do instalacji w zwykłym terminalu tekstowym (uruchamianym poleceniem cmd – command prompt):

dism /online /Enable-Feature /FeatureName:TelnetClient

Po krótkim oczekiwaniu aplikacja zostanie zainstalowana.

Na tym nie konczą się nasze możliwości ponieważ można zrobić to samo w słynnym PowerShellu. Tym razem trzeba użyć polecenia:

Install-WindowsFeature -name Telnet-Client

W szczególności to rozwiązanie wydaje się być bardzo ciekawe, a użycie polecenia Install-WindowsFeature daje nam naprawdę duże możliwości. Polecam potestować – więcej informacji można znaleźć w dokumentacji na stronach Microsoftu.

Trzeciej opcji, którą jest instalacja w trybie okienkowym, nie będę opisywał. Z premedytacją – jako zwolennik terminali tekstowych.

MG

Tagi: , , , ,

sudppipe – tunel UDP dla Windows

Luty 17th, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

UDP sudppipeSystemy serwerowe rodziny Windows stają się praktycznie niezastąpione w środowisku, gdzie jesteśmy zmuszeni korzystać z firmowych systemów bazodanowych. Oferta tych ostatnich zakłada w zasadzie wykorzystanie tylko jedynego słusznego środowiska pracy. Czasami nastręcza to nietypowych trudności, w szczególności gdy chodzi o sterowanie przepływem komunikacji. Oprogramowanie zapory sieciowej wbudowane w serwer w zasadzie nie pozwala na łatwe przekierowywanie komunikacji TCP nie wspominając już o UDP. Jeśli trafimy na środowisko homogeniczne, to skonfigurowanie wyżej wymienionych przekierowań może być trudne. Podstawowym narzędziem jest tutaj komenda linii poleceń netsh opisana w innym artykule.

Jeśli posiadamy urządzenia takie jak np. drukarki sieciowe, to przydatne staje się zarządzanie nimi za pomocą protokołu SNMP. W tym momencie może się okazać, że powinniśmy przygotować przekierowanie portów UDP na serwerze Windows. Zakładam tutaj, że drukarki sieciowe są skonfigurowane w oddzielnym VLANie, ale również w oddzielnej podsieci IP. Jeśli zatem chcielibyśmy dostać się do urządzenia SNMP z puli klienckiej (posiadającej własny VLAN) musimy włączyć tzw. port forwarding, z tym że dla UDP.

Zmagając się z opisanym problemem trafiłem na bardzo przydatne narzędzie dostępne na stronie Luigiego Auriemmy. Wśród dostępnych aplikacji znajduje się mały program o nazwie sudppipe. Wywołany z linii poleceń pozwala skonfigurować tunel UDP na serwerze Windows. Całość wygląda w działaniu zachęcająco:

Usage: sudppipe.exe [options] <server*> <server_port> <local_port>

Sprawdziłem i działa bez zarzutu. Zachęcam do szczegółowego zapoznania się z jego możliwościami.

MG

Tagi: , , ,

FTP z linii poleceń w systemie Windows

Listopad 18th, 2017 | Brak Komentarzy | Kategoria: Porady, Windows

FTPO tym, że linia poleceń w przypadku systemów takich jak Linux daje szerokie możliwości nie trzeba się specjalnie rozpisywać. Czasami jednak jesteśmy zmuszeni napisać skrypt systemowy dla serwera Windows i wtedy nie jest już tak prosto. Mam na myśli całkiem konkretny przypadek z własnego podwórka. W dużym skrócie zadanie polegało na okresowym wysyłaniu pliku baz danych MSSQL na zewnętrzny serwer FTP. Z jednej strony sprawa dosyć prosta, bo od razu przychodzi na myśl wykorzystanie harmonogramu zadań systemowych i użycie odpowiedniego skryptu wsadowego, z drugiej strony okazało się jednak, że narzędzie linii poleceń Windows takie jak komenda ftp niespecjalnie radzi sobie z trybem pasywnym transmisji. Zgodnie z dokumentacją wszystko powinno działać bez problemu, można nawet użyć spreparowanej wcześniej listy poleceń ftp, aby zautomatyzować zadanie jednak bardzo często w trakcie wykonania program zawiesza się. W sieci można znaleźć mnóstwo porad co zrobić w takiej sytuacji. Postanowiłem się tym razem podzielić innym rozwiązaniem.

W miejsce polecenia ftp można użyć dobrze znanego programu WinSCP. W skład tego pakietu wchodzi program o nazwie winscp.com, który pozwala na użycie w trybie wsadowym:

winscp.com /command "open ftp://uzytkownik:haslo@serwer.ftp/" →
→ "put plik.sql /home/user/" "exit"

Warto zwrócić tutaj uwagę na niezwykłą prostotę składni polecenia. Po przełączniku command następuje po prostu lista poleceń do wykonania. Ponieważ całość mieści się w jednej linii można w zasadzie całą komendę wpisać wprost do harmonogramu zadań systemowych. Dodatkowym plusem będzie możliwość obsługi protokołu szyfrowanego np. SFTP, czego nie potrafi zrobić narzędzie wbudowane w Windows.

MG

Tagi: , , ,