K-NET s.c.

OpenMediaVault migracja do najnowszej wersji

Jako zagorzały fanatyk OpenMediaVault nie wiedziałem dotychczas, że można dosyć łatwo i sprawnie przeprowadzić migrację do jego najnowszej wersji. Z czystego lenistwa używam OMV jako interfejsu graficznego do zarządzania serwerami i tylko w razie potrzeby zaglądam do linii poleceń. OMV można zawsze zainstalować jako dodatek do istniejącego już systemu korzystając ze skryptu instalacyjnego:

https://github.com/OpenMediaVault-Plugin-Developers/installScript

Jednak zawsze po pewnym czasie, kiedy system się starzeje a repozytoria przechodzą do archiwum może dojść do sytuacji, w której linie aktualizacji GMV oraz OS rozejdą się na tyle, że któraś z bibliotek przestanie działać albo w najgorszym razie zaktualizowana konfiguracji nie pozwoli na uruchomienie kluczowej usługi np. Dockera z całą masą krytycznych kontenerów.

W takim przypadku pozostaje wymiana OS i instalacja od nowa GMV z przeniesieniem kluczowych serwisów lub … skorzystanie z bardzo wygodnego w użyciu skryptu pozwalającego po prostu zaktualizować GMV do wyższej wersji.

Skrypt aktualizacyjny jest dołączony do narzędzi OMV i wywołujemy go poleceniem:

omv-release-upgrade

Przy odrobinie szczęścia i po odczekaniu kilkunastu minut będziemy mogli się cieszyć nową wersją OMV.

Jednak trzeba wyraźnie napisać, że tego typu “duże” aktualizacje niosą za sobą ryzyko niezgodności bibliotek, konieczności wykonania rekonfiguracji oraz poprawek systemu etc. Ja odkryłem na razie jedną dotyczącą pakietu Nginx Proxy Manager w wersji kontenerowej (Docker). Okazało się, że Nginx nie startuje podczas automatycznegi uruchomienia kontenera. W tym przypadku wystarczy uruchomić go wewnątrz kontenera ponownie po zatrzymaniu procesu na kilka sekund. Można również napisać skrypt uruchomieniowy jeśli ktoś jest bardziej ambitny. Tak czy inaczej tam gdzie drwa rąbią itd.

MG

Tagi: aktualizacja, Linux, OMV

Aktualizacja hosta ESXi

Wirtualizacja 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: aktualizacja, konfiguracja, Linux, serwer, VMWare, Windows

Homebrew autoaktualizacja – nakładka homebrew-autoupdate

Jakiś czas temu napisałem krótki artykuł [1] o tym jak uslepszyć instalację oprogramowania w systemie Mac OS X. Krótko mówiąc najlepiej jest użyć w tym celu pakietu homebrew [2]. Przyznam, że jako właściciel Macbooka Pro od około pół roku dalej drążyłem temat. Nawyki nabyte podczas użytkownia od wielu lat laptopów z Linuksem dały o sobie znać. Po jakimś czasie zauważyłem, że generalnie dążę do upodobnienia środowiska graficznego Mac OS X do Gnome/Unity [3]. Rzeczywiście jeżeli ktoś przyzwyczaił się do Unity (a wiem, że ten wynalazek Canonical [4] ma tylu samu zwolenników co przeciwników) to trudno oprzeć się wrażeniu, że środowisko jest niemal skopiowane od Apple. Jednak interfejs graficzy to jedno a narzędzia systemowe to drugie. O ile trudno się nie zgodzić, że GUI na Macu jest po prostu bardzo dopracowane i nieporównywalnie lepsze, to już wszelkie narzędzia związane z instalacją oprogramowanie i po prostu zarządzania nim to zupełnie inna bajka.

Jedną z olbrzymich zalet Linuksa jest system zarządzania aplikacjami w oparciu o repozytoria. Szczerze mówiąc nie spotkałem żadnego lepszego rozwiązania, a wszystkie sklepy Microsoftu, Apple, Google itd. są po prostu namiastką. Oczywiście zawsze na początku działa efekt wow, głównie ze względu na rzekomą łatwość obsługi i dopracowane szczegóły graficzne, ale po jakimś czasie powoli rezygnuje z korzystania z takich rozwiązań. Naprawdę, bogate narzędzia linii poleceń do instalacji oprogramowania, które oferują praktycznie wszystkie dystrybucje Linuksa, są niezastąpione.

Wspomniany na początku homebrew ma być klonem dla Mac OS X opartym o podobne mechanizmy znane z Linuksa. I wszystko byłoby w porządku gdyby nie problem autoaktualizacji pakietów. Pod tym względem niestety jest po prostu niedopracowany. I tutaj z pomocą przychodzi kolejna nakładka: homebrew-autoupdate [5]. Ujawniając trochę szczegółów – wszystko moża doczytać na stronie projektu, jej instalacja jest bardzo prosta:

brew tap domt4/autoupdate

Po zainstalowaniu narzędzia, można w końcu wydać polecenie:

brew autoupdate

aby dowiedzieć się jakie są jego możliwości, do czego gorąco zachęcam.

MG

Tagi: aktualizacja, komendy, konfiguracja, macos

Brew – wygodny instalator dla Mac OS

Macbook jako komputer do pracy kojarzy się przede wszystkim z dość drogim ale za to bardzo wydajnym rozwiązaniem na długie lata. Praktycznie każda typowa czynność została tutaj zoptymalizowana tak aby ułatwić obsługę nawet bardzo opornym użytkownikom. Można śmiało napisać, że jedna z takich funkcji obrosła już legendą, mam na myśli instalator aplikacji. Zawsze bywa podawana jako argument ‘za’ i rzeczywiście dla kogoś kto miał do czynienia tylko z systemem Windows, cały proces wydaje się nieprawdopodobnie prosty. Instaluję przeciągając program do katalogu Aplikacje, odinstalowywuje przeciągając ten sam program do Kosza.

Jednak dla kogoś kto jest przyzwyczajony np. do korzystania z repozytoriów, takie podejście wydaje się nieco dziwne. Przede wszystkim o ile producent aplikacji o to nie zadba, nie ma szans aby aktualizacje przebiegały w sposób automatyczny. Druga sprawa to przyglądając się całości od kuchni, deinstalacja wcale nie oznacza wyczyszczenia systemu z pozostałości po oprogramowaniu. Wystarczy sprawdzić dokładniej swój katalog domowy. Takie przykłady można mnożyć, niemniej nie chodzi o to aby kogoś tu zniechęcać.

Ponieważ żyjemy w bardzo różnorodnym świecie gdzie zamknięte, hermetyczne rozwiązania są praktycznie rzadkością, to okazuje się, że również Mac OS da się trochę podrasować. Z pomocą wszystkim niezadowolonym przychodzi bowiem narzędzie brew. Jego instalacja z poziomu terminala systemowego jest bardzo prosta:

ruby -e $(curl -fsSL https://raw.githubusercontent.com/ →
Homebrew/install/master/install)"

Następnie korzystając z tego samego terminala wystarczy wydać polecenie:

brew search

aby otrzymać, zadziwiająco długą listę programów, które można zainstalować komendą:

brew install {nazwa programu}

Jeśli dołożymy jeszcze polecenia takie jak:

brew update
brew doctor
brew upgrade

to widać wyraźne podobieństwo do narzędzi dobrze znanych z Linuksów.

Dalsze szczegółowe omawianie narządzia brew mija się z celem, dlatego że przede wszystkim w Internecie można znaleźć mnóstwo informacji na ten temat, a po drugie zawsze najlepiej jest pobawić się samemu. Warto jednak dodać, że zdecydowanie rzadziej można znaleźć informacje o tym, że za pomocą opisywanego instalatora można instalować również aplikacje graficzne czyli np. Chrome, Firefox oraz Gimp czy Inkscape. Wybór jest naprawdę duży. W tym przypadku trzeba skorzystać z rozszerzenia cask, czyli użyć komendy rozbudowanej np.

brew cask search

Pozostałe reguły nie zmianiają się. Jak widać za pomocą paru prostych poleceń możemy w Mac OS skorzystać z dość zaawansowanego systemu instalacji, z obsługą aktualizacji oraz  innymi ciekawymi funkcjami.

MG

Tagi: aktualizacja, komendy, Mac OS, polecenia

Ninite Pro w trybie offline

Administratorzy średnich i dużych domen Windows często muszą radzić sobie z problemem hurtowej instalacji oprogramowania na wielu końcówkach w sieci. Rozwiązania wbudowane w serwer Windows, wykorzystujące mechanizmy GPO oraz instalatory MSI nie są szczególnie wygodne. Zewnętrzne narzędzia, z których mogę polecić PDQ Deploy, są bardzo rozbudowane i nieprzejrzyste dla początkującego. Jednak od kilku lat na popularności zyskuje bardzo prosty program do instalacji o nazwie Ninite. W wersji płatnej (20 USD miesięcznie za sieć do 100 końcówek) oferuje rozbudowaną linię poleceń i dykretną instalacje silent installation, która przebiega w tle. Można zatem, uruchamiając instalator w trybie zdalnym remote install bardzo szybko aktualizować komputery bez niepokojenia użytkowników.

Ważną funkcją, która nie jest widoczna na pierwszy rzut oka jest możliwość przygotowania pliku instalacji offline korzystając z opcji freeze. Możemy przygotować w ten sposób paczkę wykonywalną EXE, którą kopiujemy np. na pendrive. Tak uzbrojony serwisant, technik czy administrator jest w stanie zaktualizować każdy komputer bez dostępu do sieci Internet! Poniżej zamieszczam postać polecenia:

NinitePro.exe /freeze /select "7-Zip" Instalator7zipOffline.exe

W przykładzie użyłem opcji select, która pozwala wybrać programy dla paczki offline. Pełną listę dostępnych aplikacji można znaleźć tutaj.

MG

Tagi: aktualizacja, linia poleceń, Windows

Preparing to configure Windows. Do not turn off your computer.

Moment aktualizowania systemu Windows jest dla mnie zawsze dość stresujący. Niestety, raz na jakiś czas, im częściej tym lepiej, należy aktualizować serwery. Przyznam, że po wielu latach, nadal mam mieszane uczucia i zdarza mi się odwlekać tę chwilę. Niedawno w trakcie aktualizacji jednego z serwerów produkcyjnych musiałem zmierzyć się ze ‘zwisem’ w trakcie wspomnianego procesu. Kiedy od godziny obserwuje się napis ‘Preparing to configure Windows. Do not turn off your computer.‘ różne myśli zaczynają chodzić po głowie. Przede wszystkim nie można ulec panice i restartować ręcznie serwera bo może się to skonczyć źle… Czy jest jakaś alternatywa?

Poniżej zamieszczam procedurę dla sytuacji, w której instalacja trwa od dłuższego czasu, RDP nie działa, jednak nadal można wykonać ping do serwera.

1. Na komputerze z systemem Windows, należy założyć konto o takiej samej nazwie użytkownika i haśle, jak konto administratora w przypadku problematycznego serwera.
2. Następuje logujemy się do świeżo utworzonego konta i uruchamiamy polecenie ‘services.msc’ oraz łączymy z serwerem.
3. Na liście aktywnych usług odnajdujemu ‘Windows modules installer‘, prawie na pewno usługa znajduje się w trybie ‘Stopping‘, nie można też ani jej zatrzymać ani zmienić konfiguracji. Właśnie ta usługa jest najczęściej odpowiedzialna za zwis podczas aktualizacji.
4. Programem/procesem, która uruchamia wspomnianą usługę jest ‘C:\windows\servicing\trustedinstaller.exe‘, musimy zatem zabić ten proces.
5. Pobieramy z Internetu narzędzie do zdalnego zarządzania procesami np. ‘http://lizardsystems.com/remote-process-explorer/‘.
6. Po zainstalowaniu narzędzia, podłączeniu do serwera i zabiciu procesu, serwer od razu przejdzie do ponownego uruchomienia systemu.

Mam nadzieję, że powyższy wpis okaże się pomocny i pozowoli szybko, w sposób cywilzowany, rozwiązać problem z aktualizacją.

MG

Tagi: aktualizacja, serwer, Windows