Bądź na bieżąco - RSS

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

Hasło root – jak je odzyskać?

Kwiecień 28th, 2019 | Brak Komentarzy | Kategoria: Linux, Porady
Hasło root

Czasami zdarza się nam zapomnieć hasła. Nie jest to żaden duży problem jeżeli np. chodzi o konto w usłudze internetowej gdzie zazwyczaj dostępna jest opcja przypomnienia za pomocą adresu e-mail. Jednak inaczej sprawa wygląda gdy zapomnieliśmy hasła administracyjnego, a jeszcze gorzej hasła administratora dla konta root w systemie opartym o jądro Linuxa. No właśnie. Pytanie brzmi jak odzyskać hasło root?

Istnieje sporo metod pozwalających odzyskać takie hasło, a dzisiaj chciałem skupić się na systemie Debian w wersji 9. Pisze o tym ponieważ całkiem niedawno padłem ofiarą własnego gapiostwa i zakładając kilka maszyn wirtualnych pod rząd zdecydowałem, że nie będę zapisywał haseł. Oczywiście przesłałem je użytkownikom ale… niestety w kilku przypadkach z błędem. Mając alternatywę przygotowywania systemów od początku i wizję kolejnych spędzonych bezproduktywnie godzin zdecydowałem się poszperać w sieci, żeby szybko odzyskać, a w zasadzie zmienić hasła.

Po lekturze kliku artykułów w sieci, ze zdziwieniniem odkryłem, że nie będę nawet musiał uruchamiać systemów z płyty instalacyjnej, ale po kolei.

Po pierwsze powinniśmy uruchomić ponownie system i w chwili pojawnienia się menu startowego z wyborem opcji uruchomieniowych zatrzymać rozruch dowolnym klawiszem (nie może to być Enter 🙂 ). Wybierając pierwszą opcje startową należy wcisnąć e aby przejść do edycji linii wywołania jądra systemowego z opcjami.

Po drugie przechodzimy do linii zaczynającej się od słowa linux, pracowicie przesuwamy się na jej koniec i dopisujemy frazę

init=/bin/bash

Po trzecie wciskamy ctrl+x lub F10 aby uruchomić system. W ten sposób wystartujemy w trybie pojedynczego użytkownika z systemem plików zamontowanym w trybie tylko-do-odczytu. Ponieważ chcemy zmienić hasło root zdecydowanie trzeba to zmienić. Wpisujemy zatem polecenie:

mount -o remount /

Po czwarte używamy dobrze znanej komendy (mam taką nadzieję)

passwd

aby zmienić hasło root. Na koniec uruchamiamy ponownie system, jednak tym razem znamy już hasło.

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

Dell R210 – instalacja sterownika sieciowego a Debian 9.6

Grudzień 15th, 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: , , , ,

PHP w dwóch wersjach jednocześnie a serwer Apache

Listopad 18th, 2018 | Możliwość komentowania PHP w dwóch wersjach jednocześnie a serwer Apache została wyłączona | Kategoria: Linux, Porady

PHP

Dla każdego administratora, który przygotowywał serwis www pojęcie LAMP nie jest obce. W skrócie oznacza, że udało nam się zainstalować trzy podstawowe serwisy tj. Apache, PHP oraz silnik bazy danych np. MySQL. Dzisiaj chciałem skupić się na obsłudze języka PHP. Obecnie ostatnią dostępną wersją jest 7.2. Domyślnie taką właśnie powinniśmy instalować. Jednak jak wiadomo rzeczywistość jest nieco bardziej skomplikowana i na pewno spotkamy się z użytkownikami, którzy z różnych względów bedą chcieli używać starszych wersji jak np. 5.6. Osobiście zalecam jak najszybsze przechodzenie do wersji najnowszych, głównie ze względu na bezpieczeństwo, trzeba jednak pamiętać o różnicach w implemetacji pomiędzy wspomnianymi wersjami, co z kolei przekłada się np. na brak niektórych funkcji, czyli na brak tak zwanej kompatybilności wstecznej. Jest to istotne przy instalacji oprogramowania webowego, które opierając się o starsze wersje PHP może nie funkcjonować w nowszym środowisku. Zatem scenariusz naszej instalacji powinien wyglądać tak, że domyślnie włączony jest PHP7 ale zawsze mamy możliwość cofnięcia wersji dla wybranych serwisów. I o tym właśnie jest dzisiejszy wpis.

Na początek załóżmy, że tradycyjnie używamy Debian Linux w wersji 9.5 Stretch. Ponieważ nie skupiamy się w tym artykule na instalacji samego Apache oraz MySQL (co z resztą jest szeroko opisywane w sieci) przejdźmy od razu do instalacji PHP. Zaczynamy od następujących poleceń:

$ apt-get install ca-certificates apt-transport-https 
$ wget -q https://packages.sury.org/php/apt.gpg -O- →
| sudo apt-key add -
$ echo "deb https://packages.sury.org/php/ stretch main" →
| sudo tee /etc/apt/sources.list.d/php.list

Aby wykorzystywać różne wersje PHP jednocześnie będziemy potrzebowali dwóch interfejsów – PHP FPM oraz FastCGI:

$ apt-get update
$ apt-get install php5.6 php5.6-fpm
$ apt-get install php7.2 php7.2-fpm

I w ten sposób zainstalujemy jednocześnie wersje 5.6 i 7.2. Oczywiście możemy tak zrobić z różnymi wydaniami, to tylko przykład.

Przechodzimy do konfiguracji samego Apache. Przede wszystkim dodajemy wspomniany interfejs:

$ apt-get install libapache2-mod-fcgid

Nastepnie włączamy następujące moduły:

$ a2enmod actions cgid alias proxy_fcgi

I to już już wszystko. Naprawdę możemy korzystać z dwóch bibliotek 🙂 . Niemniej chciałbym zasugerować włączenie domyślnie tej nanowszej. Czyli w konfiguracji głównej hosta wirtualnego (chodzi o plik 000-default.conf) dodanie następujących linijek:

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php7.2-fpm.sock|fcgi://localhost/"
</FilesMatch>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Tym razem, po ponownym uruchomieniu Apache możmy być pewni, że domyślnie używamy najnowszej zainstalowanej wersji:

$ systemctl restart apache2

Jeśli jednak któryś z użytkowników serwera będzie chciał cofnąć się z różnych względów do wersji starszej to wystarczy, że w katalogu głównym swojego serwisu utworzy tekstowy plik .htaccess i doda do niego poniższą zawartość:

<FilesMatch \.php$>
SetHandler "proxy:unix:/var/run/php/php5.6-fpm.sock|fcgi://localhost/"
</FilesMatch>

To naprawdę działa.

MG

Tagi: , , , ,

IPv6 w służbie udziałom sieciowym

Październik 21st, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

IPv6Życie lubi często płatać figle. Nierzadko stawia administratorów przed bardzo dziwnymi zadaniami, uwzględniającymi bardzo wydumane ezoteryczne scenariusze działania. Gdybym sam się z tym nie stykał na co dzień, to muszę przyznać, że byłoby mi ciężko uwierzyć. A jednak shit happens jak mawiają.

Dzisiejszy wpis dotyczy sytuacji, w której ktoś postanowił wymienić sprzęt sieciowy, w tym serwery plików NAS (tj. QNAP, Synology) i zastąpić je po prostu udziałami na serwerze plików Windows. Ponieważ nowa polityka bezpiczeństwa nie zakładała wykorzystywania rozwiązań innych niż z systemem Windows, nagle wspomniane wcześniej urządzenia zostały wyłączone. Można powiedzieć – cóż… koszty wdrożenia… ale w ten sposób pozbyto się niemałej przestrzeni dyskowej (chodziło to o kilka, kilkanaście TB), która może być zawsze wykorzystana np. do kopii zapasowych. Nietrudno się domyśleć, że powstał problem jak podłączyć z powrotem urządzenia tak aby nie naruszały zasad bezpieczeństwa. Najlepiej oczywiście lokalnie np. przez port USB, ale po pierwsze nie każde ma taką możliwość, po drugie tracimy w ten sposób masę funkcji, które są wbudowane w gotowce typu NAS. Czyli pozostaje przełożyć dyski do serwerów Windows… otóż nie do końca.

Pierwszą myślą było utworzenie osobnej podsieci lokalnej dla naszego NASa i przygotowanie na wybranym komputerze sieciowego interfejsu wirtualnego tak aby stacja mogła korzystać równocześnie z głównej podsieci i w połączeniu punkt-punkt z dysków NAS (dzięki udziałom SMB). Łatwo powiedzieć i łatwo zrobić jeśli ktoś nie rzuca kłód pod nogi. A tym razem kolejną przeszkodą był fakt, że główny interfejs sieciowy został skonfigurowany do pobierania parametrów IP przez DHCP. Niestety ani Windows 7 ani Windows 10 nie umożliwiają skonfigurowania wirtualnej karty sieciowej jeśli podstawowa korzysta z DHCP. Oczywiście w sieci można znaleźć trochę propozycji rozwiązań, jednak nie działają one wogóle, albo wymagają instalowania dodatkowego oprogramowania. Dodatkowo często po restarcie komputera cała misternie przygotowana konfiguracja idzie w cyfrową niepamięć. I właśnie w tym przypadku przydaje się IPv6.

Wystarczy otworzyć okno właściwości karty sieciowej, żeby zauważyć, że przecież oporócz IPv4 możemy skonfigurować IPv6. Na razie mało kto z tego korzysta, a bywa, że ze względów bezpieczeństwa IPv6 jest wyłączane. Tym razem możemy skonfigurować lokalną sieć IPv6 do połączenia naszego komputera z NASem. Zatem po kolei. Na komputerze Windows dodajemy IPv6 z adresem lokalnym:

fe80::208:9bff:fef9:44f

Lokalny adres IPv6 wygenerujemy przy pomocy strony https://www.ultratools.com/tools/rangeGenerator. Pamiętajmy jednak aby wybrać adres z prefiksem 64. Jest to dosyć często spotykana opcja w gotowcach typu NAS.

Na naszym urządzeniu NAS konfigurujemy IPv6 z tej samej podsieci ale np. z numerem o 1 większym. Czyli uruchamiamy kalkulator z możliwością obliczeń w zapisie szesnastkowym i do wartości 44f dodajemy 1. Powiniśmy otrzymać adres postaci:

fe80::208:9bff:fef9:450

Po restarcie obu urządzeń mamy gotową podsieć lokalną składającą się z komputera Windows i serwera NAS. Musimy tylko wiedzieć jak dostać się do dysków np. z poziomu Eksploratora Plików Windows. Otwieramy zatem eksplorator i w polu adresu wpisujemy:

\\fe80--208-9bff-fef9-450.ipv6-literal.net

Wpisywanie każdorazowo powyższego adresu jest kłopotliwe, można zatem przygotować skrót na Pulpicie albo (jeszcze lepiej) zamontować nasz udział jako lokalny katalog (C:\NAS):

mklink /D C:\NAS \\fe80--208-9bff-fef9-450.ipv6-literal.net\

Pamiętajmy jednak, że montować możemy udział sieciowy (np. \\fe80–208-9bff-fef9-450.ipv6-literal.net\kopie), więc podany przeze mnie przykład nie zadziała 😉 .

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

Kopie zapasowe w sieci Windows – część 2

Lipiec 21st, 2018 | Brak Komentarzy | Kategoria: Porady, Windows

Kopie zapasoweWe wpisie z przed dwóch miesięcy – tak, tak, mnie również dopadło wakacyjne lenistwo, opisywałem jak stworzyć listę komputerów z systemem Windows, które są aktualnie aktywne w naszej domenie lub grupie roboczej. Omówione rozwiązanie działa niezależnie od wszelkich mechanizmów wbudowanych w Active Directory czy też innych. Wspomnianą listę można zapisać np. w pliku tekstowym, po to aby w następnej kolejności zbudować skrypt wsadowy, który wykona kopie zapasowe z komputerów z listy. Ale po kolei.

Po pierwsze, trzeba zapewnić sobie dostęp do zasobów lokalnych komputerów. Jeżeli na każdym z nich mamy swoje konto administracyjne i dodatkowo wszędzie używamy tego samego konta to bardzo łatwo jest odczytać zawartość dysków twardych np. partycji systemowej C:. Nie jest tajemnicą, że w Windows tworzone są standardowe udziały sieciowe np. C$, które odpowiadają całym partycjom. Ja jednak z wielu powodów namawiałbym do utworzenia specjalnego udziału np. o nazwie Archiwum, z uprawnieniami tylko-do-odczytu dla zdalnego adminstratora. Jeśli umówimy się z użytkownikami aby tam właśnie umieszczali ważne zbiory (może to być np. folder D:/Archiwum) to wtedy pozostanie jedynie zadbać o skopiowanie całej zawartości aby zabezpieczyć się przed ewentualną utratą danych.

Jako zagorzały zwolennik Linuksa zawsze uważałem, że nie ma nic lepszego od narzędzia rsync. Jednak jego instalacja w systemie Windows wiąże się z koniecznością zainstalowania całego środowiska Cygwin, lub co najmniej jego bibliotek dll wraz ze wspomnianym narzędziem. Może jednak istnieje coś podobnego dla Windows? Tak odkryłem narzędzie robocopy. Trzeba przyznać, że ma duże możliwości i co ważne potrafi robić lustro katalogów (mirror) a jest to przecież coś o co nam chodzi przy zabezpieczaniu danych.

Ponieważ wspomniana na początku wpisu lista komputerów zawiera ich nazwy netbios (a nie adresy IP) stąd napisanie prostego batcha nie powinno być żadnym problemem. Na pewno powinien zawierać komendę jak w poniższym przykładzie:

ROBOCOPY \\nazwa_netbios\Archiwum \Archiwum_nazwa_netbios /MIR /FFT →
→ /R:3 /W:10 /Z /NP /NDL

Wywołanie robocopy z podanymi parametrami spowoduje wykonanie dokładnego lustra z udziału Archiwum na komputerze nazwa_netbios do katalogu Archiwum_nazwa_netbios na naszym serwerze z kopiami zapasowymi – czyli po prostu lokalnie. Co ważniejsze ponowne jej wywołanie spowoduje wykonanie kopii różnicowej, a więc zapewni dużo szybsze działanie.

Pozostałe opcje pozostawiam dla zainteresowanych odsyłając do dokumentacji polecenia robocopy. Na koniec nadmienię tylko, że sam cały skrypt wsadowy przygotowuje na Linkuksie przy okazji generowania listy komputerów. Jest mi łatwiej to zrobić ze względu na stare przyzwyczajenia i dostepność takich narzędzi jak chociażby awk. Myślę jednak, że równie dobrze można to zrobić w środowisku Windows. Miłej zabawy.

MG

 

Tagi: , , ,